内存泄露检测工具

                                                    MemProof教程

简介

       MemProof(内存清道夫)是AutomatedQA出品的一款非常不错的检测内存泄漏和资源泄漏的免费调试工具,适合于WIN32平台下使用DELPHI/C++ BUILDER开发的应用程序。利用它可以方便的查找出一些忘记释放的指针以及资源。它通过在调试模式下运行目标程序,监视程序的创建和释放操作,以达到检测资源泄漏的效果。监测过程中它会根据资源类型计数,每次创建后增加计数,释放则递减计数,最后程序结束根据计数即可判断出资源的泄漏。

nbsp;      MemProof的原作者是Atanas Stoyanov,后加盟了AutomatedQA公司,他目前是大名鼎鼎的AQTIME软件的主力开发者。MemProof已经很久没有更新了,作者在AutomatedQA的官方网站上也推荐大家使用AQTIMEhttp://www.automatedqa.com/products/aqtime/memproofusers.asp),因为AQTIME包含了MemProof的所有功能,并且拥有很多MemProof所不具备的特性,如:更好的COM支持,结合MSDN获取帮助,平台测试等等。虽然有这么多好处,但是AQTIME毕竟是收费的商业软件,价格不菲,而且体积相对庞大。对于我来说,更愿意选择MemProof。轻佻的体积,简单的操作,还是免费的(这条最关键~~)。当然,对于大的企业用户来说,AQTIME也是个非常不错的选择。

使用方法

l         下载

官方网站上的最新版本为 (Build 0.950 July 19, 2004)

下载地址:http://www.automatedqa.com/products/memproof/index.asp

l         安装

MemProof是一个绿色软件,下载完成后解压,运行MemProof.exe即可。

l         准备

MemProof要求目标程序带有完整的调试信息。打开工程选项(Project-Options

1、  Compiler面板

l         去掉Optimization(代码优化)选项

l         选择Stack Frames(为所有过程函数强制生成调用堆栈)选项

l         选择Debug information (DCU文件中生成调试信息)选项

l         选择Use Debug DCUS(编译时链接带有调试信息的VCL DCU文件)选项

   

 

2、  Linker面板

l         选择Detailed(生成完整的MAP文件,包含模块、单元、过程等地址信息)选项

l         选择Include TD32 debug info(将调试信息生成到可执行文件)选项

该选项会导致可执行文件体积增大,但不会影响运行效率以及内存占用,建议在正式发布时不要带上该选项。

 

 

l         开始

一切准备就绪,现在可以开始调试了。

下面是用于调试的一段测试程序:

新建一个空白工程,在OnCreate事件中加入以下代码:

procedure TForm1.FormCreate(Sender: TObject);

begin

  TFont.Create;  //创建一个TFONT对象,但不释放

  CloseHandle(0);  //关闭一个不存在的句柄

end;

再根据上面的介绍设置好工程选项。打开MemProof

 

Resources – 资源的类型,包括Error(错误)Pointers(指针)Memory(内存)、GDI(画布资源)、User(系统对象)、Kernel(核心对象)、Registry(注册表)。

Resources Count – 资源数目,Current#代表当前数目,Peak#代表峰值数目

Resources Size – 资源大小,Current#代表当前大小,Peak#代表峰值大小

 

选择File-Open 打开要调试的执行文件,再选择Run-Run 开始运行,再正常退出目标程序,如果有资源泄漏MemProof会自动打开Resources Details面板:

 

MemProof共列出5个内存泄漏,我们可以看到每个内存泄漏都有详细的调用栈情况,以及相对应的源码位置。

有时它会提示我们找不到对应的源码,这是应为没有指定源码搜索路径的原因。MemProof有两个位置可以设置源码搜索路径,一个在Configure- Search Directories,一个在Projects-Search Directories。前者是设置全局路径,后者是设置当前路径。一般建议在前者中设置DELPHIVCL以及共用库代码的路径,后者设置工程本身源码的路径。MemProof还为用户提供了快捷搜索VCL源码路径的按钮Get Default for ,使用这个按钮可以快捷的获取DELPHILibray Path(有的用户安装了VC覆盖了默认调试工具选项,所以有可能得到的是VCLibray Path,这种情况可以直接到DELPHILibray Path中去拷贝即可)。

       另外MemProof还可以记录上次的测试结果方便用户做比较,以及过滤等功能。

       如果需要测试动态连接库,可以选择Project-Parameters,在Host Applications中选择主体程序,如果需要带命令行,则在Parameters中输入命令行,然后就可以开始测试了,和DELPHI中调试的方法是一样的。

       MemProof不支持span>Attach Process的调试方式,这是一个不足的地方。

 

使用其实非常简单,一看就明白了,下面介绍些调试中的经验技巧。

技巧

l         渐进式测试,从最易发现的错误开始解决

一个大型的软件可能会有很多泄漏或者错误,这个时候可以渐进式的来测试,第一次测试可以直接运行后立即退出,检测在加载的过程中是否存在泄漏,然后逐一更正。再分功能模块进行测试,比如只针对某个功能进行操作,然后退出检测该模块是否存在泄漏,如果存在,更正。最后再进行整体测试。这样可以避免一些关联性错误导致重复测试,而且可以节省测试时间,可以使测试更有针对性。

l         分模块测试,从单个的模块开始解决

和上一条原则一样,为了缩小测试面。在ProjectsMoudle Configers中选择测试的模块,开始每次只选择一个模块针对性测试,最后再选择所有模块测试。

注意:不要选择一些如:Ole32.dllkernel32.dll等系统模块。

 

l         错误优先,发现错误与泄漏并存时,优先解决错误

测试过程中,代表错误,这些错误往往是由于错误的使用系统API导致,如:释放不存在的句柄,访问权限不够的资源,传递了错误的调用参数等。这些错误往往会导致代码没有按照预计的方式运行,触发一些内存泄漏。所以,需要优先修正这些位置。

l         系统资源优先,发现有GDIUserKernelRegistry等存在泄漏时优先解决

系统资源泄漏往往是由于窗体、画布等资源没有及时释放,这些错误非常明显,而且这种错误往往会带有很多的PointersMemory泄漏,所以,优先修正。

 

经验

l         经过实际证明,下列错误是可以忽略的

1  VirtualAlloc(00000000,4096,4096,64)   VirtualAlloc   kernel32.dll    

       这是有名的4096字节内存泄漏问题,任何使用DELPHIVCL编写的WIN32程序都会存在,这是由于在Classes单元中的MakeObjectInstance方法中使用VirtualAlloc分配了4096字节的内存,并没有释放。这不是BUG,不释放是有原因的,请参考这篇文章:

http://www.thedelphimagazine.com/samples/1328/article.htm

2OpenFileMapping

OpenFileMapping(4,0,”SMBuffer”) 导致的错误是由于BDE数据库引擎激活时,尝试OpenFileMappingSql Monitor建立链接,但是当Sql Monitor未运行时,这个mapping 并不存在,所以会导致错误。这个错误已经被VCL所捕获处理。所以可以忽略。

3、  LoadCursor

VCL并不是完美的,有时运行程序出现很多LoadCursor错误也可以忽略。

4、  其他

还有更多的关于DELPHIC++Builder本身导致的内存泄漏可以参见:

http://www.automatedqa.com/support/leaksd6.asp

 

l         发现泄漏的位置在VCL单元中的时候,不要去考究VCL的代码,找到调用栈中涉及到的外部单元去检查。相信VCL吧,绝大多数情况些它是不会导致内存泄漏的。

 

缺点

MemProof尽管非常优秀,同样存在不少缺陷。如上面提到的不能Attach Process,这样就不能够调试ISAPI、服务程序等;还有,当程序由于访问保护内存、或强制结束进程等原因导致非正常退出时,MemProof将不会有任何结果报告;另外,MemProof的机制决定它不可能实现远程调试;最后,MemProof是个免费性质的软件,在帮助支持方面做得不够,连一个像样的帮助都没有,同类的商业软件BoundCheker在这方面做得非常不错,每个错误都可以在帮助中得到详细的解释,MemProof的这个缺点导致新手不容易上手。

总结

      关于MemProof就介绍到这里了。总之,瑕不掩瑜,/span>MemProof依然是广大DELPHI/C++BUILER爱好者的开发利器。

感谢Atanas Stoyanov的无私奉献。

猜你喜欢

转载自jsrgren.iteye.com/blog/1634094