资源预览内容
第1页 / 共12页
第2页 / 共12页
第3页 / 共12页
第4页 / 共12页
第5页 / 共12页
第6页 / 共12页
第7页 / 共12页
第8页 / 共12页
第9页 / 共12页
第10页 / 共12页
亲,该文档总共12页,到这儿已超出免费预览范围,如果喜欢就下载吧!
资源描述
浅谈C/C+内存泄漏及其检测工具2006-04-03 09:00 作者: 出处: 温馨小屋 责任编辑:方舟 对于一个c/c+程序员来说,内存泄漏是一个常见的也是令人头疼的问题。已经有许多技术被研究出来以应对这个问题,比如Smart Pointer,Garbage Collection等。Smart Pointer技术比较成熟,STL中已经包含支持 Smart Pointer的class,但是它的使用似乎并不广泛,而且它也不能解决所有的问题;Garbage Collection技术在Java 中已经比较成熟,但是在c/c+领域的发展并不顺畅,虽然很早就有人思考在C+中也加入GC的支持。现实世界就是这样的,作为一个c/c+程序员,内存泄漏是你心中永远的痛。不过好在现在有许多工具能够帮助我们验证内存泄漏的存在,找出发生问题的代码。内存泄漏的定义 一般我们常说的内存泄漏是指堆内存的泄漏。堆内存是指程序从堆中分配的,大小任意的(内存块的大小可以在程序运行期决定) ,使用完后必须显示释放的内存。应用程序一般使用malloc, realloc,new 等函数从堆中分配到一块内存,使用完后,程序必须负责相应的调用free或delete释放该内存块,否则,这块内存就不能被再次使用,我们就说这块内存泄漏了。以下这段小程序演示了堆内存发生泄漏的情形:void MyFunction(int nSize)char* p= new charnSize;if( !GetStringFrom( p, nSize ) )MessageBox(“Error”);return;/using the string pointed by p;delete p;例一当函数GetStringFrom()返回零的时候,指针p指向的内存就不会被释放。这是一种常见的发生内存泄漏的情形。程序在入口处分配内存,在出口处释放内存,但是c函数可以在任何地方退出,所以一旦有某个出口处没有释放应该释放的内存,就会发生内存泄漏。广义的说,内存泄漏不仅仅包含堆内存的泄漏,还包含系统资源的泄漏(resource leak),比如核心态HANDLE,GDI Object,SOCKET, Interface等,从根本上说这些由操作系统分配的对象也消耗内存,如果这些对象发生泄漏最终也会导致内存的泄漏。而且,某些对象消耗的是核心态内存,这些对象严重泄漏时会导致整个操作系统不稳定。所以相比之下,系统资源的泄漏比堆内存的泄漏更为严重。GDI Object的泄漏是一种常见的资源泄漏:void CMyView:OnPaint( CDC* pDC )CBitmap bmp;CBitmap* pOldBmp;bmp.LoadBitmap(IDB_MYBMP);pOldBmp = pDC-SelectObject( &bmp );if( Something() )return;pDC-SelectObject( pOldBmp );return;例二当函数Something() 返回非零的时候,程序在退出前没有把pOldBmp选回pDC 中,这会导致pOldBmp指向的 HBITMAP对象发生泄漏。这个程序如果长时间的运行,可能会导致整个系统花屏。这种问题在Win9x下比较容易暴露出来,因为Win9x的GDI堆比Win2k或NT的要小很多。内存泄漏的发生方式:以发生的方式来分类,内存泄漏可以分为4类:1. 常发性内存泄漏。发生内存泄漏的代码会被多次执行到,每次被执行的时候都会导致一块内存泄漏。比如例二,如果Something()函数一直返回True ,那么pOldBmp指向的HBITMAP对象总是发生泄漏。2. 偶发性内存泄漏。发生内存泄漏的代码只有在某些特定环境或操作过程下才会发生。比如例二,如果Something() 函数只有在特定环境下才返回True ,那么pOldBmp指向的HBITMAP对象并不总是发生泄漏。常发性和偶发性是相对的。对于特定的环境,偶发性的也许就变成了常发性的。所以测试环境和测试方法对检测内存泄漏至关重要。3. 一次性内存泄漏。发生内存泄漏的代码只会被执行一次,或者由于算法上的缺陷,导致总会有一块仅且一块内存发生泄漏。比如,在类的构造函数中分配内存,在析构函数中却没有释放该内存,但是因为这个类是一个Singleton,所以内存泄漏只会发生一次。另一个例子:char* g_lpszFileName = NULL;void SetFileName( const char* lpcszFileName )if( g_lpszFileName )free( g_lpszFileName );g_lpszFileName = strdup( lpcszFileName );例三如果程序在结束的时候没有释放g_lpszFileName指向的字符串,那么,即使多次调用SetFileName(),总会有一块内存,而且仅有一块内存发生泄漏。4. 隐式内存泄漏。程序在运行过程中不停的分配内存,但是直到结束的时候才释放内存。严格的说这里并没有发生内存泄漏,因为最终程序释放了所有申请的内存。但是对于一个服务器程序,需要运行几天,几周甚至几个月,不及时释放内存也可能导致最终耗尽系统的所有内存。所以,我们称这类内存泄漏为隐式内存泄漏。举一个例子: class Connectionpublic:Connection( SOCKET s);Connection();private:SOCKET _socket;class ConnectionManagerpublic:ConnectionManager()ConnectionManager()list:iterator it;for( it = _connlist.begin(); it != _connlist.end(); +it )delete (*it);_connlist.clear();void OnClientConnected( SOCKET s )Connection* p = new Connection(s);_connlist.push_back(p);void OnClientDisconnected( Connection* pconn )_connlist.remove( pconn );delete pconn;private:list _connlist;例四假设在Client从Server端断开后,Server并没有呼叫OnClientDisconnected()函数,那么代表那次连接的Connection对象就不会被及时的删除(在Server程序退出的时候,所有Connection对象会在ConnectionManager的析构函数里被删除) 。当不断的有连接建立、断开时隐式内存泄漏就发生了。从用户使用程序的角度来看,内存泄漏本身不会产生什么危害,作为一般的用户,根本感觉不到内存泄漏的存在。真正有危害的是内存泄漏的堆积,这会最终消耗尽系统所有的内存。从这个角度来说,一次性内存泄漏并没有什么危害,因为它不会堆积,而隐式内存泄漏危害性则非常大,因为较之于常发性和偶发性内存泄漏它更难被检测到。 检测内存泄漏检测内存泄漏的关键是要能截获住对分配内存和释放内存的函数的调用。截获住这两个函数,我们就能跟踪每一块内存的生命周期,比如,每当成功的分配一块内存后,就把它的指针加入一个全局的list中;每当释放一块内存,再把它的指针从list 中删除。这样,当程序结束的时候,list中剩余的指针就是指向那些没有被释放的内存。这里只是简单的描述了检测内存泄漏的基本原理,详细的算法可以参见Steve Maguire的。如果要检测堆内存的泄漏,那么需要截获住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:TestMemLeakTestDlg.cpp(70) : 59 normal block at 0x00881710, 200 bytes long.Data: 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_FILEstatic 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 char200;经过宏替换就变成了:char* p = new( THIS_FILE, _LINE_)char200;根据C+的标准,对于以上的new的使用方法,编译器会去找这样定义的operator new:void* operator new(size_t, LPCSTR, int)我们在afxmem.cpp 63行找到了一个这样的operator new 的实现void* AFX_
网站客服QQ:2055934822
金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号