查看: 3995|回复: 3
[AIX] 请问怎么在AIX下查看某特定进程占用内存的情况
论坛徽章:0
我想测试此程序是否有内存泄漏。
请各位援手。
论坛徽章:0
# ps aux|sort +2 -rn|head -20
论坛徽章:3
svmon -p/-P pid
论坛徽章:3
最初由 xysco 发布
[B]svmon -p/-P pid [/B]
主要看 inuse 大小的变化情况
itpub.net All Right Reserved. 北京皓辰网域网络信息技术有限公司版权所有　　　　
　北京市公安局海淀分局网监中心备案编号：　广播电视节目制作经营许可证：编号（京）字第1149号2087人阅读
内存泄露简单的说就是申请了一块内存空间，使用完毕后没有释放掉。它的一般表现方式是程序运行时间越长，占用内存越多，最终用尽全部内存，整个。
封装 new 和 delete 对内存泄漏进行分析
通过对 new 和 delete 的封装，将 new 和 delete 的过程通过日志文件的保存记录下来。然后对日志文件进行分析，是否 new 和 delete 是匹配的，有哪些内存申请，但是没有释放。
下面通过一个简单的测试程序（此代码使用 C++ 语言实现，目前没有考虑申请数组的情况）进行演示：
这个测试程序申请了 pTemp1，pTemp2，pTemp3 的三块内存，但是仅仅释放了 pTemp3，存在 pTemp1 和 pTemp2 的内存泄露。
程序解释：
在每次内存申请时，将内存申请的信息注册到 MAP 表中，在每次内存释放时，将对应的内存信息从注册表中删除，这样注册表中将保存未释放的内存信息，按照一定的规则将注册表中的信息输出（定时或者进程退出等）。然后我们从输出信息中便可以分析出内存泄漏点。
通过自定义宏 DEMONEW 和 DEMODELETE 申请内存和释放内存，在这两个宏中，我们将内存的申请和释放做了记录，从而可以得到未释放内存的信息，请参考下面的程序实现流程图：
测试程序代码：
#include &map&
#include &iostream&
#include &string&
#include &fstream&
// 申请内存时，存储 new 位置的数据结构
typedef struct {
} MEMINFO;
// 输出文件
std::ofstream loginfo(&//tmp/memory.log&);
typedef std::map&long long, MEMINFO& MemM
// 存储内存申请记录（在每次内存申请时，将内存申请的地址作为键值，
// 内存申请操作所在的文件名和行号作为内容，存储到下面的数据结构 memmap 中）
// 注册内存申请信息到上面的 map 容器中，输入的参数分别为内存地址，文件名，行号
void RegMemInfo(long long addr, const char *fname, long long lnum)
if (fname)
info.filename =
info.line =
memmap.insert(MemMap::value_type(addr, info));
// 卸载内存申请信息从上面的 map 容器中，输入的参数为内存地址
void UnRegMemInfo(long long addr)
if (memmap.end() != memmap.find(addr))
memmap.erase(addr);
// 定义宏 DEMONEW，封装了内存申请的操作，在内存申请成功后，调用 RegMemInfo 功能，
// 将内存信息注册到 map 容器中
#define DEMONEW(p, ptype)\
RegMemInfo((long long)p, __FILE__, __LINE__);\
std::cout&&&NEW failed&&&std::\
// 定义宏 DEMODELETE，封装了内存释放的操作，在内存释放时，调用 UnRegMemInfo
// 功能，将内存信息从 map 容器中删除
#define DEMODELETE(p) \
UnRegMemInfo((long long)p);\
// 写信息流内容到文件
void WriteString(std::string buf)
loginfo && buf &&std::
// 将整数转换为字符串
std::string Int2Str(int value)
char buf[16] = {0};
sprintf(buf, &%d&, value);
// 输出 map 容器中存储的内存没有释放的信息
void Output()
loginfo.clear();
if (memmap.empty())
WriteString(&No Memory leak.&);
WriteString(&The Memory leak is below:&);
for (iter = memmap.begin(); iter != memmap.end(); ++iter)
std::string sAddr = Int2Str(iter-&first);
std::string sLine = Int2Str(iter-&second.line);
buf += &memory Address &;
buf += sA
buf += &: FILE &;
buf += iter-&second.
buf += &, LINE &;
buf += sL
buf += & no freed&;
WriteString(buf);
// 测试程序主入口函数
int main(int argc,
char* argv[])
char* pTemp1 = 0;
DEMONEW(pTemp1, char);
char* pTemp2 = 0;
DEMONEW(pTemp2, char);
char* pTemp3 = 0;
DEMONEW(pTemp3, char);
DEMODELETE(pTemp1);
loginfo.close();
上面测试程序的输出是：
[dyu@xilinuxbldsrv ~]$ vi /tmp/memory.log
The Memory leak is below:
memory Address : FILE test.cpp, LINE 109 no freed
memory Address : FILE test.cpp, LINE 111 no freed
输出分析：
从输出结果我们可以发现，此测试程序在 test.cpp 文件的 109 和 111 行各有一处内存泄漏，查看源代码，它们分别是 pTemp1 和 pTemp2。
使用 Purify（适用所有 UNIX 平台）或者 valgrind（适用 Linux 平台）工具对内存泄漏进行分析
使用 Purify 对内存泄漏进行分析
Purify 是 IBM Rational PurifyPlus 的工具之一， 是一个面向 VC、VB 或者 Java 开发的测试 Visual C/C++ 和 Java 代码中与内存有关的错误的工具，它确保整个应用程序的质量和可靠性。在查找典型的 C/C++ 程序中的传统内存访问错误， Rational Purify 可以大显身手。在 UNIX 系统中，使用 Purify 需要重新编译程序。通常的做法是修改 Makefile 中的编译器变量。
例如定义 CC 变量为 purify gcc
CC=purify gcc
首先运行 Purify 安装目录下的 purifyplus_setup.sh 来设置环境变量，然后运行 make 重新编译程序。需要指出的是，程序必须编译成调试版本。在编译器命令（例如 Solaris 的 CC 编译器，Linux 的 gcc 编译器等）后，也就是必须使用&-g&选项。在重新编译的程序运行结束后，Purify 会打印出一个分析报告。
测试程序（此代码使用 C++ 语言实现）：
#include &stdlib.h&
void func1()
//char* pBuf =
void func2()
char* pBuf =
void func3()
char* pBuf =
int main()
编译程序：
[dyu@xilinuxbldsrv purify]$ purify g++ -g tst.cpp -o tst1
Purify 输出：
[dyu@xilinuxbldsrv purify]$ ./tst1
16:50:59 (rational) OUT: &PurifyPlusUNIX& dyu@xilinuxbldsrv
Purify instrumented ./tst1 (pid 530 at Fri Apr
6 16:50:59 2012)
* Purify 7.0.0.0-014 090319 Linux (64-bit) (C) Copyright IBM Corporation. 1992,
* 2009 All Rights Reserved.
* For contact information type: &purify -help&
* For Purify Viewer output, set the DISPLAY environment variable.
* License successfully checked out.
* Command-line: ./tst1
* Options settings: -g++=yes -purify \
-purify-home=
/home/dyu/purify/PurifyPlus.7.0.0.0-014/Rational/releases/\
purify.i386_linux2.7.0.0.0-014
-process-large-objects=yes -gcc3_path=/usr/bin/g++ \
-cache-dir=
/home/dyu/purify/PurifyPlus.7.0.0.0-014/Rational/releases/\
purify.i386_linux2.7.0.0.0-014\
Purify instrumented ./tst1 (pid 530)
Current file descriptors in use: 5
FIU: file descriptor 0: &stdin&
FIU: file descriptor 1: &stdout&
FIU: file descriptor 2: &stderr&
FIU: file descriptor 26: &reserved for Purify internal use&
FIU: file descriptor 27: &reserved for Purify internal use&
Purify instrumented ./tst1 (pid 530)
Purify: Searching for all memory leaks...
Memory leaked: 2 bytes (100%); potentially leaked: 0 bytes (0%)
MLK: 1 byte leaked at 0xa457098
* This memory was allocated from:
operator new(unsigned long) [libstdc++.so.6]
operator new(unsigned long) [rtlib.o]
[tst.cpp:9]
[tst.cpp:20]
__libc_start_main [libc.so.6]
MLK: 1 byte leaked at 0xa457138
* This memory was allocated from:
operator new(unsigned long) [libstdc++.so.6]
operator new(unsigned long) [rtlib.o]
[tst.cpp:14]
[tst.cpp:21]
__libc_start_main [libc.so.6]
Purify Heap Analysis (combining suppressed and unsuppressed blocks)
Potentially Leaked
----------------------------------------
Total Allocated
Purify 图形输出：
安装 Xmanager 等工具，设置 DISPLAY 为本机 IP，见下图：
[dyu@xilinuxbldsrv purify]$ export DISPLAY=9.119.131.33:0
输出分析：
从 purify 的输出可以看出，此测试程序存在两处内存泄漏，它分别是 func2 和 func3，在 tst.cpp 文件的第 9 和第 14 行。
使用 valgrind（现在仅仅支持 Linux 平台）对内存泄漏进行分析
Valgrind 是一套 Linux 下，开放源代码（GPL V2）的仿真调试工具的集合。Valgrind 由内核（core）以及基于内核的其他调试工具组成。内核类似于一个框架，它模拟了一个 CPU 环境，并提供服务给其他工具；而其他工具则类似于插件 (plug-in)，利用内核提供的服务完成各种特定的内存调试任务。Valgrind 在对程序进行侦测的时候，不需要对程序进行重新编译。
下面使用 valgrind 对一个简单的测试程序进行。
测试程序：
同 Purify 的测试程序相同。
编译程序：
[dyu@xilinuxbldsrv purify]$ g++ -g tst.cpp -o tst
valgrind 输出：
[dyu@xilinuxbldsrv purify]$ valgrind --leak-check=full ./tst
==25396== Memcheck, a memory error detector
==25396== Copyright (C) , and GNU GPL'd, by Julian Seward et al.
==25396== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info
==25396== Command: ./tst
==25396== HEAP SUMMARY:
in use at exit: 2 bytes in 2 blocks
total heap usage: 2 allocs, 0 frees, 2 bytes allocated
==25396== 1 bytes in 1 blocks are definitely lost in loss record 1 of 2
at 0x4A0666E: operator new(unsigned long) (vg_replace_malloc.c:220)
by 0x4005C7: func2() (tst.cpp:9)
by 0x4005DB: main (tst.cpp:20)
==25396== 1 bytes in 1 blocks are definitely lost in loss record 2 of 2
at 0x4A0666E: operator new(unsigned long) (vg_replace_malloc.c:220)
by 0x4005AF: func3() (tst.cpp:14)
by 0x4005E0: main (tst.cpp:21)
==25396== LEAK SUMMARY:
definitely lost: 2 bytes in 2 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 0 bytes in 0 blocks
suppressed: 0 bytes in 0 blocks
==25396== For counts of detected and suppressed errors, rerun with: -v
==25396== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 4 from 4)
[dyu@xilinuxbldsrv purify]$
输出分析：
从 valgrind 的输出可以看出，此测试程序存在两处内存泄漏，它分别是 func2 和 func3，在 tst.cpp 文件的第 9 和第 14 行，与 purify 的检测结果相同。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：31791次
排名：千里之外
转载：43篇
(1)(1)(1)(5)(8)(28)(1)程序写累了，就来玩玩酷跑小游戏吧，嘿嘿。
雨松MOMO送你一首歌曲，嘿嘿。
Android研究院之内存泄漏调试学习与总结(二十二)
Android研究院之内存泄漏调试学习与总结(二十二)
围观5411次
编辑日期： 字体：
开始学习啦，吼吼，小马很尽量写清楚自己想的与学习到的知识，希望大家不要嫌啰嗦，仔细看下小马描述与扩展的知识，一定能学到东西的！
好了，先简单说下，大家有或经常碰到OOM的问题，对吧？很多这样的问题只要一出现相信大家的想法跟小马的一样，就是自己的应用：优化、优化、再优化！而且如果出现类似于OOM这样级别的问题，根本就不好处理，LogCat日志中显示的信息仅仅是OOM，并不会给你提示如何解决的方法或思路，因为引起OOM的原因是你应用的问题，不是系统问题！应该想下，在优化之前找到需要优化的地方，再去做优化操作不是更直接吗？相信大多数朋友应该经常听过或使用Jnuit调试吧，好了，废话不多说，今天小马就跟大家一起来学习总结下OOM的调试方法，来找到需要优化的地方，要知道OOM也是可以一步步调试的:
首先，先一起来做些小小的知识铺垫：
Android(Java)中常见的容易引起内存泄漏的不良代码：
1. 查询数据库没有关闭游标
程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险示例代如下码：
1234567891011121314151617181920
Cursor cursor = getContentResolver().query(uri ...);if (cursor.moveToNext()) {&&... ...&&} 修正示例代码：Cursor cursor = null;try {&&cursor = getContentResolver().query(uri ...);&&if (cursor != null && cursor.moveToNext()) {&&... ...&&&&}} finally {&&if (cursor != null) {&&try {&&&&cursor.close();&&} catch (Exception e) {&&//ignore this&&}&&}}
2. 构造Adapter时，没有使用缓存的 convertView ，这个问题小马上一篇：ListView加载数据原理及优化总结（二十一）中已经讲过了，大家可以回过头看下
3. Bitmap对象不在使用时调用recycle()没有及时释放
如果一个Bitmap对象比较占内存，当它不在被使用的时候，可以调用Bitmap.recycle()方法回收此对象的像素所占用的内存
4.没有及时释放对象的引用
简单举个例子：比如两个Activity之间传递的Context 或其它的自定义对象，使用完后必须立即释放 即：Activity =
Context = Object =可以的话在这释放对象之后通知系统来回收：System.gc();这样最好了！
Android主要应用在嵌入式设备当中，而嵌入式设备由于一些众所周知的条件限制，通常都不会有很高的配置，特别是内存是比较有限的。如果我们编写的代 码当中有太多的对内存使用不当的地方，难免会使得我们的设备运行缓慢，甚至是死机。为了能够使得Android应用程序安全且快速的运行，Android 的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行，它是由Zygote服务进程演变过来的，也就是说每个应用程序都是在属于自己的进程中运行的（问题一：这个地方小马怎么知道是在属于自己的进程中运行的？大家继续，答案小马会在下面详细介绍）。一方面，如果程序在运行过程中出现了内存泄漏的问题，仅仅会使得自己的进程被杀掉，而不会影响其他进程（如果是system_process 等系统进程出问题的话，则会引起系统重启）。另一方面Android为不同类型的进程分配了不同的内存使用上限，如果应用进程使用的内存超过了这个上限， 则会被系统视为内存泄漏，从而被杀掉
下面小马来解释下问题一：”每个应用程序都是在属于自己的进程中运行的”这句话，对于这句话，大家只记住一点：“当一个程序第一次启动的时候，Android会启动一个LINUX进程和一个主线程。默认的情况下，所有该程序的组件都将在该进程和线程中运行。”~^_^
O_O ！！！
同时，Android会为每个应用程序分配一个单独的LINUX用户。Android会尽量保留一个正在运行进程，只在内存资源出现不足时，Android会尝试停止一些进程从而释放足够的资源给其他新的进程使用， 也能保证用户正在访问的当前进程有足够的资源去及时地响应用户的事件。Android会根据进程中运行的组件类别以及组件的状态来判断该进程的重要性，Android会首先停止那些不重要的进程。按照重要性从高到低一共有五个级别就是我们常说的：前台进程、可见进程、服务进程、后台进程、空进程（此处概念略，大家自己查）
还有个小扩展：当一个程序第一次启动时，Android会同时启动一个对应的主线程（Main Thread），主线程主要负责处理与UI相关的事件，如用户的按键事件，用户接触屏幕的事件以及屏幕绘图事件，并把相关的事件分发到对应的组件进行处理。所以主线程通常又被叫做UI线程。在开发Android应用时必须遵守单线程模型的原则： Android UI操作并不是线程安全的并且这些操作必须在UI线程中执行。Android的UI是单线程(Single-threaded)的。为了避免拖住GUI，一些较费时的对象应该交给独立的线程去执行。如果幕后的线程来执行UI对象，Android就会发出错误讯息 CalledFromWrongThreadException。以后遇到这样的异常抛出时就要知道怎么回事咯！
好了，铺垫知识就写这么多了，下面直接进入主题了：OOM调试
方式一：使用内存监测工具 DDMS –& Heap：（真机、模拟器均可使用）
1. 启动eclipse后，切换到DDMS透视图，并确认Devices视图、Heap视图都是打开的，没打开的直接Window&ShowView&自己选；
2. 将手机通过USB链接至电脑，链接时需要确认手机是处于“USB调试”模式
3. 链接成功后，在DDMS的Devices视图中将会显示手机设备的序列号，以及设备中正在运行的部分进程信息；
4. 点击选中想要监测的进程，如果在进程列表中未出现你的进程的话随便选中一条让Device一排的工具处于可用状态，再点击下Update Heap让其自动找到我们跑的应用的进程，比如小马临时跑的两个应用进程如图；
5. 点击Heap视图中的“Cause GC”按钮；
6.点击Cause GC之后就可以看到我们应用的内存情况如下图：
a) 点击“Cause GC”按钮相当于向虚拟机请求了一次gc操作；
b) 当内存使用信息第一次显示以后，无须再不断的点击“Cause GC”，Heap视图界面会定时刷新，在对应用的不断的操作过程中就可以看到内存使用的变化；
c) 内存使用信息的各项参数根据名称即可知道其意思，不知道具体意思的朋友自行用工具（有道、词霸查去）
知道工具使用了，那么如何才能知道我们的程序是否有内存泄漏的可能性呢。这里需要注意一个值：Heap视图中部有一个Type叫做data object，即数据对象，也就是我们的程序中大量存在的类类型的对象。在data object一行中有一列是“Total Size”，其值就是当前进程中所有Java数据对象的内存总量，如果大家想要看“Total Size”是分配的具体信息可以点击“data object这一行来查看详细信息，如下图”（大家看不清楚的点击看大图）
一般情况下，在data object行的“Total Size”这个值的大小决定了是否会有内存泄漏。可以这样判断：
a) 不断的操作当前应用，同时注意观察data object的Total Size值；
b) 正常情况下Total Size值都会稳定在一个有限的范围内，也就是说由于程序中的的代码良好，没有造成对象不被垃圾回收的情况，所以说虽然我们不断的操作会不断的生成很多对 象，而在虚拟机不断的进行GC的过程中，这些对象都被回收了，内存占用量会会落到一个稳定的水平；
c) 反之如果代码中存在没有释放对象引用的情况，则data object的Total Size值在每次GC后不会有明显的回落，随着操作次数的增多Total Size的值会越来越大，
直到到达一个上限后导致进程被杀掉。
Android为应用进程分配的内存上限如下所示：（下面这些是小马网上查到的，小马不懂下面的语法，但知道有限制这么一回事就够了，此处不研究下面的代码）
位置： /ANDROID_SOURCE/system/core/rootdir/init.rc 部分脚本
# Define the oom_adj values for the classes of processes that can be
# killed by the kernel. These are used in ActivityManagerService.
setprop ro.FOREGROUND_APP_ADJ 0
setprop ro.VISIBLE_APP_ADJ 1
setprop ro.SECONDARY_SERVER_ADJ 2
setprop ro.BACKUP_APP_ADJ 2
setprop ro.HOME_APP_ADJ 4
setprop ro.HIDDEN_APP_MIN_ADJ 7
setprop ro.CONTENT_PROVIDER_ADJ 14
setprop ro.EMPTY_APP_ADJ 15
# Define the memory thresholds at which the above process classes will
# be killed. These numbers are in pages (4k).
setprop ro.FOREGROUND_APP_MEM 1536
setprop ro.VISIBLE_APP_MEM 2048
setprop ro.SECONDARY_SERVER_MEM 4096
setprop ro.BACKUP_APP_MEM 4096
setprop ro.HOME_APP_MEM 4096
setprop ro.HIDDEN_APP_MEM 5120
setprop ro.CONTENT_PROVIDER_MEM 5632
setprop ro.EMPTY_APP_MEM 6144
# Write value must be consistent with the above properties.
# Note that the driver only supports 6 slots, so we have HOME_APP at the
# same memory level as services.
write /sys/module/lowmemorykiller/parameters/adj 0,1,2,7,14,15
write /proc/sys/vm/overcommit_memory 1
write /proc/sys/vm/min_free_order_shift 4
write /sys/module/lowmemorykiller/parameters/minfree 96,44
# Set init its forked children’s oom_adj.
write /proc/1/oom_adj -16
d) 此处以com.xiaoma.www进程为例，在我的测试环境中com.xiaoma.www进程所占用的内存的data object的Total Size正常情况下稳定在0.8~1.0M之间，而当其值超过3~5M每次启动应用该值不稳定的时候进程就会被系统杀掉啦！
内存监测工具 DDMS –& Heap
使用内存分析工具 MAT(Memory Analyzer Tool)
(一) 生成.hprof文件 （生成很简单，直接点击Device 工具栏中的 Dump HPROF file即可生成）
(二) 使用MAT导入.hprof文件
(三) 使用MAT的视图工具分析内存
总之，使用DDMS的Heap视图工具可以很方便的确认我们的程序是否存在内存泄漏的可能性。这个地方顺带着也简单的说一下，如果大家想要跟踪更详细的内存是怎样分配的话，可以学着使用下Windows&ShowView&Allocation Tracker工具来定位你的内存什么时候被什么东西占用了，是bundlea或HashMap或ArrayList焦点或是其它的什么占用了这些都可以在这个插件中查看到的，简单的使用方法就是：选中Device进程列表中的某一个进程，让Allocation Tracker里面的跟踪工具处于可用状态，点击Stop Tracking来跟踪程序，过一定时间后，点击Get Allocations来获取内存分配的消息就可以查看更为详细的内存分配情况了,如下图：
Allocation Tracker这个小工具比较简单， 小马在这个地方不一一说明了，想学的朋友们自己点击看看就会知道里面的参数是什么意思了…..^_^……..最后，还是一样，小马在内存管理方面还要学的东西很多，如果文章中小马有讲的不清楚或不足之处，大家留言批评并提出更好的建议，小马一定及时改进，在此先谢谢大家啦，吼吼学习学习！大家加油，一起进步！！！
本文固定链接:
转载请注明:
雨松MOMO提醒您：亲，如果您觉得本文不错，快快将这篇文章分享出去吧 。另外请点击网站顶部彩色广告或者捐赠支持本站发展，谢谢！
作者：小马果
【誓言、会老】…【承诺、会变】…【目标、遥远】…【选择、不后悔】…【对自己要狠】…所有动力，源自兴趣,爱编程，更过编程的过程.....
如果您愿意花10块钱请我喝一杯咖啡的话，请用手机扫描二维码即可通过支付宝直接向我捐款哦。
您可能还会对这些文章感兴趣！您所在位置： &
&nbsp&&nbsp&nbsp&&nbsp
内存泄漏静态检测模型的设计和实现.pdf59页
本文档一共被下载：
次 ,您可全文免费在线阅读后下载本文档。
文档加载中...广告还剩秒
需要金币：200 &&
你可能关注的文档：
··········
··········
硼HE DESIGNAND IMPLEMEN咖0N OFS1 舰C MEMORYI甩AK DETECTION MODEL Itisthemostdifficultissuetodetect errorsinsoftwareof memory C． 舡theC hasthe of and its languageadvantageflexibilityefficiency,from born until isthe now,it main which programminglanguagehasbeen used．C allowsusers widely
language tocontroltheuseofmemory resources is for or directly,whichvery importanthigh―performance hign
utilizationof resources．Buttheflexible computer memorymanagement leadto leaksand
may other errors．InC memory memory programs leakiS iSdifficulttobe
memoryverydanger’it
theaccumulationof will failures，the be program’Sperformancelower,
and itwillleadtoserious finally crashor unexpectedlyquit．Therefore leak detectioniscrucial!
memory Firstofall，this researchesonthe leakdetection paper memory themethodsof
technology,and leak analyzes memorydetection， stmic their
including testing，dynamictesting，andcompare advantages
and theauthorbuiltthe static tools disadvantages．Then testingDTSC，
realizeditssyntaxanalysis，lexical tableandcontrol analysis，symbol
flow on authoraddedthe these，the interval ofeach graph，base analysis
variableto the the of that improve theauthor accuracyanalysis．After
builtastatic on basisofstatemachinewith up testingplatform stzong then and theC codes
expansion．Andbystudyingsummarizing languge
whichwill leak and generatememory fault，designimplement memory III
北京邮电大学硕士研究生学位论文 Abstract C
leakmodefor useittotest DTSC，and programs．Finally,thispaper thetestresultswith static the tools，analyze
compares foreigntesting ofDTSC
leak andweaknesses model，and
strengths memory gives to DTSC and leakmode． memory improveplatform
suggestions
KEY leak；Static analysis；Defect WORDS：Memorytesting；Interval machine mode；State 独创性 或创新性 声明 本人声明所呈交的论文是本人在导师指导下进行的研究工作及取得
正在加载中，请稍后...