一.内存泄漏的定义
一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的,大小任意的(内存块的大小可以在程序运行期决定),使用完后必须显示释放的内存。应用程序一般使用malloc,realloc,new等函数从堆中分配到一块内存,使用完后,程序必须负责相应的调用free或delete释放该内存块,否则,这块内存就不能被再次使用,我们就说这块内存泄漏了。以下这段小程序演示了堆内存发生泄漏的情形:
二.内存泄漏的发生方式
1. 常发性内存泄漏。发生内存泄漏的代码会被多次执行到,每次被执行的时候都会导致一块内存泄漏。
2. 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。常发性和偶发性是相对的。对于特定的环境,偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。
3. 一次性内存泄漏。发生内存泄漏的代码只会被执行一次,或者由于算法上的缺陷,导致总会有一块且仅有一块内存发生泄漏。
4. 隐式内存泄漏。程序在运行过程中不停的分配内存,但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏,因为最终程序释放了所有申请的内存。但是对于一个服务器程序,需要运行几天,几周甚至几个月,不及时释放内存也可能导致最终耗尽系统的所有内存。所以,我们称这类内存泄漏为隐式内存泄漏。
三.内存泄漏的表现
Private Bytes和Virtual Bytes至少有一个是一条斜向上曲线,大多数泄漏是这种情况
如果Private Byte和Virtual Bytes一起上升,但是后者比前者上升得快或者比例超过3:1,说明不仅仅有内存泄漏,而且泄漏导致了内存碎片
四.常用的两种检查内存泄漏的方式:
1. 调试器和CRT调试堆函数
用MFC开发的应用程序,在DEBUG版模式下编译后,都会自动加入内存泄漏的检测代码。在程序结束后,如果发生了内存泄漏,在Debug窗口中会显示出所有发生泄漏的内存块的信息,以下两行显示了一块被泄漏的内存块的信息:
E:\TestMemLeak\TestDlg.cpp(70) : {59} normal block at 0x00881710, 200 bytes long.
Data:
第一行显示该内存块由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 |
有了这样的定义,在编译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) |
第二个operator new函数比较长,为了简单期间,我只摘录了部分。很显然最后的内存分配还是通过_malloc_dbg函数实现的,这个函数属于MS C-Runtime Library 的Debug Function。这个函数不但要求传入内存的大小,另外还有文件名和行号两个参数。文件名和行号就是用来记录此次分配是由哪一段代码造成的。如果这块内存在程序结束之前没有被释放,那么这些信息就会输出到Debug窗口里。
要在非MFC程序中打开内存泄漏的检测功能非常容易,你只要在程序的入口处加入以下几行代码:
int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG ); |
这样,在程序结束的时候,也就是winmain,main或dllmain函数返回之后,如果还有内存块没有释放,它们的信息会被打印到Debug窗口里。
如果你试着创建了一个非MFC应用程序,而且在程序的入口处加入了以上代码,并且故意在程序中不释放某些内存块,你会在Debug窗口里看到以下的信息:
{47} normal block at 0x00C91C90, 200 bytes long. |
内存泄漏的确检测到了,但是和上面MFC程序的例子相比,缺少了文件名和行号。对于一个比较大的程序,没有这些信息,解决问题将变得十分困难。
为了能够知道泄漏的内存块是在哪里分配的,你需要实现类似MFC的映射功能,把new,maolloc等函数映射到_malloc_dbg函数上。
实现方式详见:http://www.cnblogs.com/skynet/archive/2011/02/20/1959162.html
2.利用第三方工具检
第三方监测工具有很多,这里选取几款比较好用的推荐给大家
Visual Leak Detecter
应用环境:Windows + VC
编程语言:C/C++
使用方法:只需包含头文件vld.h,并添加提供的lib
结果输出:输出到VC的调试窗口中
设计思路: 注册_CrtSetAllocHook钩子函数,使用VC自带的CRT Debug Heap
优缺点:可以获得内存泄露点的调用堆栈,可以得到内存泄露的完整数据
如何获取:http://www.codeproject.com/Articles/9815/Visual-Leak-Detector-Enhanced-Memory-Leak-Detectio
Bounds Checker
应用环境:Windows + VC6.0
编程语言:C/C++
使用方法:安装使用,会自动在VC内创建右键菜单
结果输出:输出到VC的调试窗口中
设计思路: 未知
优缺点:可以检测内存泄露;资源泄漏;对指针的错误操作,内存读、写溢出;使用未初始化的内存
如何获取:http://3ddown.com/soft/31594.htm,安装licence时,需要将日期调整为2008年,然后安装licence。有一个licence安装后显示是8.3的,但是可以使用。
mtrace
应用环境:Linux GLIBC
编程语言:C
使用方法: 包含头文件mcheck.h,定义环境变量MALLOC_TRACE为输出文件名,程序开始时调用mtrace()即可。
结果输出:用户指定的文件
设计思路: 为malloc,realloc,free函数添加钩子函数,记录每一对malloc-free的执行
优缺点:只能检查使用malloc/realloc/free造成的的内存泄露
如何获取:GLIBC自带,可直接使用
memwatch
应用环境:Linux
编程语言:C
使用方法: 加入memwatch.h,编译时加上-DMEMWATCH -DMW_STDIO及memwatch.c
结果输出:输出文件名称为memwatch.log,在程序执行期间,错误提示都会显示在stdout上
设计思路:将malloc/realloc/calloc/strdup/free等重定义为mwMalloc(sz, __FILE__, __LINE__)等,内部维护一个操作链表
优缺点:能检测双重释放(double-free)、错误释放(erroneous free)、内存泄漏(unfreed memory)、溢出(Overflow)、下溢(Underflow)等等
如何获取:http://memwatch.sourceforge.net/
valgrind
应用环境:Linux
编程语言:C/C++
使用方法: 加入memwatch.h,编译时加上-DMEMWATCH -DMW_STDIO及memwatch.c
结果输出:输出文件名称为memwatch.log,在程序执行期间,错误提示都会显示在stdout上
设计思路:根据软件的内存操作维护一个有效地址空间表和无效地址空间表(进程的地址空间)
优缺点:能够检测:
使用未初始化的内存 (Use of uninitialised memory)
使用已经释放了的内存 (Reading/writing memory after it has been free’d)
使用超过 malloc分配的内存空间(Reading/writing off the end of malloc’d blocks)
对堆栈的非法访问 (Reading/writing inappropriate areas on the stack)
申请的空间是否有释放 (Memory leaks – where pointers to malloc’d blocks are lost forever)
如何获取:http://valgrind.org/
debug_new
应用环境:Linux/Windows
编程语言:C++
使用方法: 包含头文件debug_new.h,链接debug_new.cpp
结果输出:控制台console
设计思路: 通过重载new和delete操作符来捕获内存申请/释放请求,并在程序内部维护一个全局静态变量的哈希链表。在new操作符中,不仅仅分配用户所要求的内存,而是在为每次分配的内存都添加一个头部,存储着此次分配的位置信息和链表指针,new返回的是分配的这块内存加上头部偏移后的值,而在之前已经将此返回值作了HASH计算并添加到HASH链表中了。delete的时候先根据要释放的指针地址做HASH计算,然后再遍历数组HASH值处的链表进行查找,如果找到则将该节点移除,未找到就abort。这样在程序结束之后,通过检查此数组中是否还有未释放的内存块来确定是否有内存泄露。
优缺点:跨平台,仅用于C++程序,
如何获取:http://www.ibm.com/developerworks/cn/linux/l-mleak2/index.html
工具原理分析
以上的这些分析工具,所使用的方法大致分为以下几种:
1、注册内存分配/释放钩子函数(hook)。在Linux下可以malloc_hook, free_hook等5个钩子函数,在Windows下可以注册_CrtSetAllocHook钩子函数,这样在分配内存的时候就可以捕获这一请求并加以处理。Visual Leak Detecter和mtrace使用此方式。
2、使用宏定义替换。将用户代码中的malloc, free 替换为宏定义的 mwMalloc(sz, __FILE__, __LINE__)等自定义函数,从而跟踪内存请求,memwatch即使用此方式。
3、操作符重载。此方法仅用于C++语言中,通过重载new、delete操作符来实现跟踪内存请求,重载后的操作符类似于钩子函数意义。debug_new采用此方式。
这些工具的输出方式也分以下几种:
1、Windows VC环境下一般输出到调试窗口中,因此VC本身就提供了一个理想的输出场所,并且GUI应用程序输出到标准输出时不可见的。Visual Leak Detecter采用此法。
2、输出到标准输出或标准错误输出:控制台应用程序可以输出到屏幕,如memwatch, valgrind, debug_new都是采用这种方法。
3、输出到日志文件:将结果输出到用户指定或默认的日志文件中,如mtrace和memwatch。
此外,这些工具的内存检测方式无非也分为两种:
1、维护一个内存操作链表,当有内存申请操作时,将其加入此链表中,当有释放操作时,从申请操作从链表中移除。如果到程序结束后此链表中还有内容,说明有内存泄露了;如果要释放的内存操作没有在链表中找到对应操作,则说明是释放了多次。使用此方法的有VC内置的调试工具,Visual Leak Detecter,mtrace, memwatch, debug_new。
2、模拟进程的地址空间。仿照操作系统对进程内存操作的处理,在用户态下维护一个地址空间映射,此方法要求对进程地址空间的处理有较深的理解。因为Windows的进程地址空间分布不是开源的,所以模拟起来很困难,因此只支持Linux。采用此方法的是valgrind。
总结:
检测内存泄漏的关键是要能截获住对分配内存和释放内存的函数的调用。截获住这两个函数,我们就能跟踪每一块内存的生命周期,比如,每当成功的分配一块内存后,就把它的指针加入一个全局的list中;每当释放一块内存,再把它的指针从list中删除。这样,当程序结束的时候,list中剩余的指针就是指向那些没有被释放的内存。如果要检测堆内存的泄漏,那么需要截获住malloc/realloc/free和new/delete就可以了(其实new/delete最终也是用malloc/free的,所以只要截获前面一组即可)。对于其他的泄漏,可以采用类似的方法,截获住相应的分配和释放函数。比如,要检测BSTR的泄漏,就需要截获SysAllocString/SysFreeString;要检测HMENU的泄漏,就需要截获CreateMenu/ DestroyMenu。(有的资源的分配函数有多个,释放函数只有一个,比如,SysAllocStringLen也可以用来分配BSTR,这时就需要截获多个分配函数)