memproof来对程序进行检查内存泄漏

要使用memproof来对程序进行检查内存泄漏等，步骤如下：
1. 先配置delphi的编译环境，以便输出相应的信息，给memproof使用
2. 将程序编译好，然后再打开memproof，在memproof里打开该程序的可执行文件，
3.操作程序，查看memproof所报的一些信息，
4. 退出程序， 此时memproof会报出有内存泄漏或是别的；

配置delphi的编译环境按如下来进行：
1. 打开delphi, Project==>Options,
    (1) Compiler面板:去掉Optimization（代码优化）选项;
    (2) 选上Stack Frames（为所有过程函数强制生成调用堆栈）选项;
    (3) 选择Debug information (在DCU文件中生成调试信息)选项;
    (4)  选择Use Debug DCUS（编译时链接带有调试信息的VCL DCU文件）选项
2.   Linker面板
     (1) 选择Detailed（生成完整的MAP文件，包含模块、单元、过程等地址信息）选项;
     (2) 选择Include TD32 debug info（将调试信息生成到可执行文件）选项, 该选项会导致可执行文件体积增大，但不会影响运行效率以及内存占用，建议在正式发布时不要带上该选项。

-----------------------------------------------------------------------------------------------
开始

一切准备就绪，现在可以开始调试了。
1. 下面是用于调试的一段测试程序：

新建一个空白工程，在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。前者是设置全局路径，后者是设置当前路径。一般建议在前者中设置DELPHI的VCL以及共用库代码的路径，后者设置工程本身源码的路径。MemProof还为用户提供了快捷搜索VCL源码路径的按钮Get Default for ，使用这个按钮可以快捷的获取DELPHI的Libray Path（有的用户安装了VC覆盖了默认调试工具选项，所以有可能得到的是VC的Libray Path，这种情况可以直接到DELPHI的Libray Path中去拷贝即可）。

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

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

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

-------------------------------------------------------------------------------------------------------------------

技巧
1. 渐进式测试，从最易发现的错误开始解决

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

2. 分模块测试，从单个的模块开始解决

和上一条原则一样，为了缩小测试面。在Projects的Moudle Configers中选择测试的模块，开始每次只选择一个模块针对性测试，最后再选择所有模块测试。
注意：不要选择一些如：Ole32.dll、kernel32.dll等系统模块。

3. 错误优先，发现错误与泄漏并存时，优先解决错误

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

 
4. 系统资源优先，发现有GDI、User、Kernel、Registry等存在泄漏时优先解决

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

 
-------------------------------------------------------------------------------------------------------------------------------------

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

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

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

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

2、OpenFileMapping

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

3、  LoadCursor

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

4、  其他

还有更多的关于DELPHI和C++Builder本身导致的内存泄漏可以参见：

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

 

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

 

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

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

感谢Atanas Stoyanov的无私奉献。

文章出处：http://www.diybl.com/course/4_webprogram/asp.net/netjs/2008422/111349.html