浅谈C/C 内存泄漏及其检测工具

2008-02-23 05:27:20来源:互联网 阅读 ()

新老客户大回馈,云服务器低至5折

 检测内存泄漏

  检测内存泄漏的关键是要能截获住对分配内存和释放内存的函数的调用。截获住这两个函数,我们就能跟踪每一块内存的生命周期,比如,每当成功的分配一块内存后,就把他的指针加入一个全局的list中;每当释放一块内存,再把他的指针从list中删除。这样,当程式结束的时候,list中剩余的指针就是指向那些没有被释放的内存。这里只是简单的描述了检测内存泄漏的基本原理,周详的算法能够参见Steve Maguire的<<Writing Solid Code>>。

  假如要检测堆内存的泄漏,那么需要截获住malloc/realloc/free和new/delete就能够了(其实new/delete最终也是用malloc/free的,所以只要截获前面一组即可)。对于其他的泄漏,能够采用类似的方法,截获住相应的分配和释放函数。比如,要检测BSTR的泄漏,就需要截获SysAllocString/SysFreeString;要检测HMENU的泄漏,就需要截获CreateMenu/ DestroyMenu。(有的资源的分配函数有多个,释放函数只有一个,比如,SysAllocStringLen也能够用来分配BSTR,这时就需要截获多个分配函数)

  在Windows平台下,检测内存泄漏的工具常用的一般有三种,MS C-Runtime Library内建的检测功能;外挂式的检测工具,诸如,Purify,BoundsChecker等;利用Windows NT自带的Performance Monitor。这三种工具各有优缺点,MS C-Runtime Library虽然功能上较之外挂式的工具要弱,但是他是免费的;Performance Monitor虽然无法标示出发生问题的代码,但是他能检测出隐式的内存泄漏的存在,这是其他两类工具无能为力的地方。

  以下我们周详讨论这三种检测工具:

  VC下内存泄漏的检测方法

  用MFC研发的应用程式,在DEBUG版模式下编译后,都会自动加入内存泄漏的检测代码。在程式结束后,假如发生了内存泄漏,在Debug窗口中会显示出任何发生泄漏的内存块的信息,以下两行显示了一块被泄漏的内存块的信息:

E:\TestMemLeak\TestDlg.cpp(70) : {59} normal block at 0x00881710, 200 bytes long.

Data: <abcdefghijklmnop> 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70

  第一行显示该内存块由TestDlg.cpp文档,第70行代码分配,地址在0x00881710,大小为200字节,{59}是指调用内存分配函数的Request Order,关于他的周详信息能够参见MSDN中_CrtSetBreakAlloc()的帮助。第二行显示该内存块前16个字节的内容,尖括号内是以ASCII方式显示,接着的是以16进制方式显示。

  一般大家都误以为这些内存泄漏的检测功能是由MFC提供的,其实不然。MFC只是封装和利用了MS C-Runtime Library的Debug Function。非MFC程式也能够利用MS C-Runtime Library的Debug Function加入内存泄漏的检测功能。MS C-Runtime Library在实现malloc/free,strdup等函数时已内建了内存泄漏的检测功能。

  注意观察一下由MFC Application Wizard生成的项目,在每一个cpp文档的头部都有这样一段宏定义:

#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif


  有了这样的定义,在编译DEBUG版时,出现在这个cpp文档中的任何new都被替换成DEBUG_NEW了。那么DEBUG_NEW是什么呢?DEBUG_NEW也是个宏,以下摘自afx.h,1632行

#define DEBUG_NEW new(THIS_FILE, __LINE__)


  所以假如有这样一行代码:

char* p = new char[200];


  经过宏替换就变成了:

char* p = new( THIS_FILE, __LINE__)char[200];


  根据C 的标准,对于以上的new的使用方法,编译器会去找这样定义的operator new:

void* operator new(size_t, LPCSTR, int)


  我们在afxmem.cpp 63行找到了一个这样的operator new 的实现

void* AFX_CDECL operator new(size_t nSize, LPCSTR lpszFileName, int nLine)
{
 return ::operator new(nSize, _NORMAL_BLOCK, lpszFileName, nLine);
}

void* __cdecl operator new(size_t nSize, int nType, LPCSTR lpszFileName, int nLine)
{
 …
 pResult = _malloc_dbg(nSize, nType, lpszFileName, nLine);
 if (pResult != NULL)
  return pResult;
 …
}


  第二个operator new函数比较长,为了简单期间,我只摘录了部分。很显然最后的内存分配还是通过_malloc_dbg函数实现的,这个函数属于MS C-Runtime Library 的Debug Function。这个函数不但需要传入内存的大小,另外更有文档名和行号两个参数。文档名和行号就是用来记录此次分配是由哪一段代码造成的。假如这块内存在程式结束之前没有被释放,那么这些信息就会输出到Debug窗口里。

  这里顺便提一下THIS_FILE,__FILE和__LINE__。__FILE__和__LINE__都是编译器定义的宏。当碰到__FILE__时,编译器会把__FILE__替换成一个字符串,这个字符串就是当前在编译的文档的路径名。当碰到__LINE__时,编译器会把__LINE__替换成一个数字,这个数字就是当前这行代码的行号。在DEBUG_NEW的定义中没有直接使用__FILE__,而是用了THIS_FILE,其目的是为了减小目标文档的大小。假设在某个cpp文档中有100处使用了new,假如直接使用__FILE__,那编译器会产生100个常量字符串,这100个字符串都是飧?/SPAN>cpp文档的路径名,显然十分冗余。假如使用THIS_FILE,编译器只会产生一个常量字符串,那100处new的调用使用的都是指向常量字符串的指针。

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇: 内存陷阱 驯服C 中的野指针

下一篇: Bjarne:如何对付内存泄漏?