對(duì)于一個(gè)c/c++程序員來(lái)說(shuō)，內(nèi)存泄漏是一個(gè)常見(jiàn)的也是令人頭疼的問(wèn)題。已經(jīng)有許多技術(shù)被研究出來(lái)以應(yīng)對(duì)這個(gè)問(wèn)題，比如Smart Pointer，Garbage Collection等。Smart Pointer技術(shù)比較成熟，STL中已經(jīng)包含支持Smart Pointer的class，但是它的使用似乎并不廣泛，而且它也不能解決所有的問(wèn)題；Garbage Collection技術(shù)在Java中已經(jīng)比較成熟，但是在c/c++領(lǐng)域的發(fā)展并不順暢，雖然很早就有人思考在C++中也加入GC的支持。現(xiàn)實(shí)世界就是這樣的，作為一個(gè)c/c++程序員，內(nèi)存泄漏是你心中永遠(yuǎn)的痛。不過(guò)好在現(xiàn)在有許多工具能夠幫助我們驗(yàn)證內(nèi)存泄漏的存在，找出發(fā)生問(wèn)題的代碼。
內(nèi)存泄漏的定義 一般我們常說(shuō)的內(nèi)存泄漏是指堆內(nèi)存的泄漏。堆內(nèi)存是指程序從堆中分配的，大小任意的（內(nèi)存塊的大小可以在程序運(yùn)行期決定），使用完后必須顯示釋放的內(nèi)存。應(yīng)用程序一般使用malloc，realloc，new等函數(shù)從堆中分配到一塊內(nèi)存，使用完后，程序必須負(fù)責(zé)相應(yīng)的調(diào)用free或delete釋放該內(nèi)存塊，否則，這塊內(nèi)存就不能被再次使用，我們就說(shuō)這塊內(nèi)存泄漏了。以下這段小程序演示了堆內(nèi)存發(fā)生泄漏的情形：
void MyFunction(int nSize)
{
char* p= new char[nSize];
if( !GetStringFrom( p, nSize ) ){
MessageBox(“Error”);
return;
}
…//using the string pointed by p;
delete p;
} |
例一
當(dāng)函數(shù)GetStringFrom()返回零的時(shí)候，指針p指向的內(nèi)存就不會(huì)被釋放。這是一種常見(jiàn)的發(fā)生內(nèi)存泄漏的情形。程序在入口處分配內(nèi)存，在出口處釋放內(nèi)存，但是c函數(shù)可以在任何地方退出，所以一旦有某個(gè)出口處沒(méi)有釋放應(yīng)該釋放的內(nèi)存，就會(huì)發(fā)生內(nèi)存泄漏。
廣義的說(shuō)，內(nèi)存泄漏不僅僅包含堆內(nèi)存的泄漏，還包含系統(tǒng)資源的泄漏(resource leak)，比如核心態(tài)HANDLE，GDI Object，SOCKET， Interface等，從根本上說(shuō)這些由操作系統(tǒng)分配的對(duì)象也消耗內(nèi)存，如果這些對(duì)象發(fā)生泄漏最終也會(huì)導(dǎo)致內(nèi)存的泄漏。而且，某些對(duì)象消耗的是核心態(tài)內(nèi)存，這些對(duì)象嚴(yán)重泄漏時(shí)會(huì)導(dǎo)致整個(gè)操作系統(tǒng)不穩(wěn)定。所以相比之下，系統(tǒng)資源的泄漏比堆內(nèi)存的泄漏更為嚴(yán)重。
GDI Object的泄漏是一種常見(jiàn)的資源泄漏：
void CMyView::OnPaint( CDC* pDC )
{
CBitmap bmp;
CBitmap* pOldBmp;
bmp.LoadBitmap(IDB_MYBMP);
pOldBmp = pDC->SelectObject( &bmp );
…
if( Something() ){
return;
}
pDC->SelectObject( pOldBmp );
return;
} |
例二
當(dāng)函數(shù)Something()返回非零的時(shí)候，程序在退出前沒(méi)有把pOldBmp選回pDC中，這會(huì)導(dǎo)致pOldBmp指向的HBITMAP對(duì)象發(fā)生泄漏。這個(gè)程序如果長(zhǎng)時(shí)間的運(yùn)行，可能會(huì)導(dǎo)致整個(gè)系統(tǒng)花屏。這種問(wèn)題在Win9x下比較容易暴露出來(lái)，因?yàn)閃in9x的GDI堆比Win2k或NT的要小很多。
內(nèi)存泄漏的發(fā)生方式：
以發(fā)生的方式來(lái)分類(lèi)，內(nèi)存泄漏可以分為4類(lèi)：
1. 常發(fā)性?xún)?nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼會(huì)被多次執(zhí)行到，每次被執(zhí)行的時(shí)候都會(huì)導(dǎo)致一塊內(nèi)存泄漏。比如例二，如果Something()函數(shù)一直返回True，那么pOldBmp指向的HBITMAP對(duì)象總是發(fā)生泄漏。
2. 偶發(fā)性?xún)?nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼只有在某些特定環(huán)境或操作過(guò)程下才會(huì)發(fā)生。比如例二，如果Something()函數(shù)只有在特定環(huán)境下才返回True，那么pOldBmp指向的HBITMAP對(duì)象并不總是發(fā)生泄漏。常發(fā)性和偶發(fā)性是相對(duì)的。對(duì)于特定的環(huán)境，偶發(fā)性的也許就變成了常發(fā)性的。所以測(cè)試環(huán)境和測(cè)試方法對(duì)檢測(cè)內(nèi)存泄漏至關(guān)重要。
3. 一次性?xún)?nèi)存泄漏。發(fā)生內(nèi)存泄漏的代碼只會(huì)被執(zhí)行一次，或者由于算法上的缺陷，導(dǎo)致總會(huì)有一塊僅且一塊內(nèi)存發(fā)生泄漏。比如，在類(lèi)的構(gòu)造函數(shù)中分配內(nèi)存，在析構(gòu)函數(shù)中卻沒(méi)有釋放該內(nèi)存，但是因?yàn)檫@個(gè)類(lèi)是一個(gè)Singleton，所以?xún)?nèi)存泄漏只會(huì)發(fā)生一次。另一個(gè)例子：
char* g_lpszFileName = NULL;
void SetFileName( const char* lpcszFileName )
{
if( g_lpszFileName ){
free( g_lpszFileName );
}
g_lpszFileName = strdup( lpcszFileName );
} |
例三
如果程序在結(jié)束的時(shí)候沒(méi)有釋放g_lpszFileName指向的字符串，那么，即使多次調(diào)用SetFileName()，總會(huì)有一塊內(nèi)存，而且僅有一塊內(nèi)存發(fā)生泄漏。
4. 隱式內(nèi)存泄漏。程序在運(yùn)行過(guò)程中不停的分配內(nèi)存，但是直到結(jié)束的時(shí)候才釋放內(nèi)存。嚴(yán)格的說(shuō)這里并沒(méi)有發(fā)生內(nèi)存泄漏，因?yàn)樽罱K程序釋放了所有申請(qǐng)的內(nèi)存。但是對(duì)于一個(gè)服務(wù)器程序，需要運(yùn)行幾天，幾周甚至幾個(gè)月，不及時(shí)釋放內(nèi)存也可能導(dǎo)致最終耗盡系統(tǒng)的所有內(nèi)存。所以，我們稱(chēng)這類(lèi)內(nèi)存泄漏為隱式內(nèi)存泄漏。舉一個(gè)例子：
class Connection
{
public:
Connection( SOCKET s);
~Connection();
…
private:
SOCKET _socket;
…
};
class ConnectionManager
{
public:
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;
}; |
例四
假設(shè)在Client從Server端斷開(kāi)后，Server并沒(méi)有呼叫OnClientDisconnected()函數(shù)，那么代表那次連接的Connection對(duì)象就不會(huì)被及時(shí)的刪除（在Server程序退出的時(shí)候，所有Connection對(duì)象會(huì)在ConnectionManager的析構(gòu)函數(shù)里被刪除）。當(dāng)不斷的有連接建立、斷開(kāi)時(shí)隱式內(nèi)存泄漏就發(fā)生了。
從用戶(hù)使用程序的角度來(lái)看，內(nèi)存泄漏本身不會(huì)產(chǎn)生什么危害，作為一般的用戶(hù)，根本感覺(jué)不到內(nèi)存泄漏的存在。真正有危害的是內(nèi)存泄漏的堆積，這會(huì)最終消耗盡系統(tǒng)所有的內(nèi)存。從這個(gè)角度來(lái)說(shuō)，一次性?xún)?nèi)存泄漏并沒(méi)有什么危害，因?yàn)樗粫?huì)堆積，而隱式內(nèi)存泄漏危害性則非常大，因?yàn)檩^之于常發(fā)性和偶發(fā)性?xún)?nèi)存泄漏它更難被檢測(cè)到。
檢測(cè)內(nèi)存泄漏
檢測(cè)內(nèi)存泄漏的關(guān)鍵是要能截獲住對(duì)分配內(nèi)存和釋放內(nèi)存的函數(shù)的調(diào)用。截獲住這兩個(gè)函數(shù)，我們就能跟蹤每一塊內(nèi)存的生命周期，比如，每當(dāng)成功的分配一塊內(nèi)存后，就把它的指針加入一個(gè)全局的list中；每當(dāng)釋放一塊內(nèi)存，再把它的指針從list中刪除。這樣，當(dāng)程序結(jié)束的時(shí)候，list中剩余的指針就是指向那些沒(méi)有被釋放的內(nèi)存。這里只是簡(jiǎn)單的描述了檢測(cè)內(nèi)存泄漏的基本原理，詳細(xì)的算法可以參見(jiàn)Steve Maguire的<<Writing Solid Code>>。
如果要檢測(cè)堆內(nèi)存的泄漏，那么需要截獲住malloc/realloc/free和new/delete就可以了（其實(shí)new/delete最終也是用malloc/free的，所以只要截獲前面一組即可）。對(duì)于其他的泄漏，可以采用類(lèi)似的方法，截獲住相應(yīng)的分配和釋放函數(shù)。比如，要檢測(cè)BSTR的泄漏，就需要截獲SysAllocString/SysFreeString；要檢測(cè)HMENU的泄漏，就需要截獲CreateMenu/ DestroyMenu。（有的資源的分配函數(shù)有多個(gè)，釋放函數(shù)只有一個(gè)，比如，SysAllocStringLen也可以用來(lái)分配BSTR，這時(shí)就需要截獲多個(gè)分配函數(shù)）
在Windows平臺(tái)下，檢測(cè)內(nèi)存泄漏的工具常用的一般有三種，MS C-Runtime Library內(nèi)建的檢測(cè)功能；外掛式的檢測(cè)工具，諸如，Purify，BoundsChecker等；利用Windows NT自帶的Performance Monitor。這三種工具各有優(yōu)缺點(diǎn)，MS C-Runtime Library雖然功能上較之外掛式的工具要弱，但是它是免費(fèi)的；Performance Monitor雖然無(wú)法標(biāo)示出發(fā)生問(wèn)題的代碼，但是它能檢測(cè)出隱式的內(nèi)存泄漏的存在，這是其他兩類(lèi)工具無(wú)能為力的地方。
以下我們?cè)敿?xì)討論這三種檢測(cè)工具：
VC下內(nèi)存泄漏的檢測(cè)方法
用MFC開(kāi)發(fā)的應(yīng)用程序，在DEBUG版模式下編譯后，都會(huì)自動(dòng)加入內(nèi)存泄漏的檢測(cè)代碼。在程序結(jié)束后，如果發(fā)生了內(nèi)存泄漏，在Debug窗口中會(huì)顯示出所有發(fā)生泄漏的內(nèi)存塊的信息，以下兩行顯示了一塊被泄漏的內(nèi)存塊的信息：
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
第一行顯示該內(nèi)存塊由TestDlg.cpp文件，第70行代碼分配，地址在0x00881710，大小為200字節(jié)，{59}是指調(diào)用內(nèi)存分配函數(shù)的Request Order，關(guān)于它的詳細(xì)信息可以參見(jiàn)MSDN中_CrtSetBreakAlloc()的幫助。第二行顯示該內(nèi)存塊前16個(gè)字節(jié)的內(nèi)容，尖括號(hào)內(nèi)是以ASCII方式顯示，接著的是以16進(jìn)制方式顯示。
一般大家都誤以為這些內(nèi)存泄漏的檢測(cè)功能是由MFC提供的，其實(shí)不然。MFC只是封裝和利用了MS C-Runtime Library的Debug Function。非MFC程序也可以利用MS C-Runtime Library的Debug Function加入內(nèi)存泄漏的檢測(cè)功能。MS C-Runtime Library在實(shí)現(xiàn)malloc/free，strdup等函數(shù)時(shí)已經(jīng)內(nèi)建了內(nèi)存泄漏的檢測(cè)功能。
注意觀察一下由MFC Application Wizard生成的項(xiàng)目，在每一個(gè)cpp文件的頭部都有這樣一段宏定義：
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif |
有了這樣的定義，在編譯DEBUG版時(shí)，出現(xiàn)在這個(gè)cpp文件中的所有new都被替換成DEBUG_NEW了。那么DEBUG_NEW是什么呢？DEBUG_NEW也是一個(gè)宏，以下摘自afx.h，1632行
| #define DEBUG_NEW new(THIS_FILE, __LINE__) |
所以如果有這樣一行代碼：
經(jīng)過(guò)宏替換就變成了：
| char* p = new( THIS_FILE, __LINE__)char[200]; |
根據(jù)C++的標(biāo)準(zhǔn)，對(duì)于以上的new的使用方法，編譯器會(huì)去找這樣定義的operator new：
| void* operator new(size_t, LPCSTR, int) |
我們?cè)赼fxmem.cpp 63行找到了一個(gè)這樣的operator new 的實(shí)現(xiàn)
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;
…
} |
第二個(gè)operator new函數(shù)比較長(zhǎng)，為了簡(jiǎn)單期間，我只摘錄了部分。很顯然最后的內(nèi)存分配還是通過(guò)_malloc_dbg函數(shù)實(shí)現(xiàn)的，這個(gè)函數(shù)屬于MS C-Runtime Library 的Debug Function。這個(gè)函數(shù)不但要求傳入內(nèi)存的大小，另外還有文件名和行號(hào)兩個(gè)參數(shù)。文件名和行號(hào)就是用來(lái)記錄此次分配是由哪一段代碼造成的。如果這塊內(nèi)存在程序結(jié)束之前沒(méi)有被釋放，那么這些信息就會(huì)輸出到Debug窗口里。
這里順便提一下THIS_FILE，__FILE和__LINE__。__FILE__和__LINE__都是編譯器定義的宏。當(dāng)碰到__FILE__時(shí)，編譯器會(huì)把__FILE__替換成一個(gè)字符串，這個(gè)字符串就是當(dāng)前在編譯的文件的路徑名。當(dāng)碰到__LINE__時(shí)，編譯器會(huì)把__LINE__替換成一個(gè)數(shù)字，這個(gè)數(shù)字就是當(dāng)前這行代碼的行號(hào)。在DEBUG_NEW的定義中沒(méi)有直接使用__FILE__，而是用了THIS_FILE，其目的是為了減小目標(biāo)文件的大小。假設(shè)在某個(gè)cpp文件中有100處使用了new，如果直接使用__FILE__，那編譯器會(huì)產(chǎn)生100個(gè)常量字符串，這100個(gè)字符串都是飧?/SPAN>cpp文件的路徑名，顯然十分冗余。如果使用THIS_FILE，編譯器只會(huì)產(chǎn)生一個(gè)常量字符串，那100處new的調(diào)用使用的都是指向常量字符串的指針。
再次觀察一下由MFC Application Wizard生成的項(xiàng)目，我們會(huì)發(fā)現(xiàn)在cpp文件中只對(duì)new做了映射，如果你在程序中直接使用malloc函數(shù)分配內(nèi)存，調(diào)用malloc的文件名和行號(hào)是不會(huì)被記錄下來(lái)的。如果這塊內(nèi)存發(fā)生了泄漏，MS C-Runtime Library仍然能檢測(cè)到，但是當(dāng)輸出這塊內(nèi)存塊的信息，不會(huì)包含分配它的的文件名和行號(hào)。
要在非MFC程序中打開(kāi)內(nèi)存泄漏的檢測(cè)功能非常容易，你只要在程序的入口處加入以下幾行代碼：
int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );
tmpFlag |= _CRTDBG_LEAK_CHECK_DF;
_CrtSetDbgFlag( tmpFlag ); |
這樣，在程序結(jié)束的時(shí)候，也就是winmain，main或dllmain函數(shù)返回之后，如果還有內(nèi)存塊沒(méi)有釋放，它們的信息會(huì)被打印到Debug窗口里。
如果你試著創(chuàng)建了一個(gè)非MFC應(yīng)用程序，而且在程序的入口處加入了以上代碼，并且故意在程序中不釋放某些內(nèi)存塊，你會(huì)在Debug窗口里看到以下的信息：
{47} normal block at 0x00C91C90, 200 bytes long.
Data: < > 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F |
內(nèi)存泄漏的確檢測(cè)到了，但是和上面MFC程序的例子相比，缺少了文件名和行號(hào)。對(duì)于一個(gè)比較大的程序，沒(méi)有這些信息，解決問(wèn)題將變得十分困難。
為了能夠知道泄漏的內(nèi)存塊是在哪里分配的，你需要實(shí)現(xiàn)類(lèi)似MFC的映射功能，把new，maolloc等函數(shù)映射到_malloc_dbg函數(shù)上。這里我不再贅述，你可以參考MFC的源代碼。
由于Debug Function實(shí)現(xiàn)在MS C-RuntimeLibrary中，所以它只能檢測(cè)到堆內(nèi)存的泄漏，而且只限于malloc，realloc或strdup等分配的內(nèi)存，而那些系統(tǒng)資源，比如HANDLE，GDI Object，或是不通過(guò)C-Runtime Library分配的內(nèi)存，比如VARIANT，BSTR的泄漏，它是無(wú)法檢測(cè)到的，這是這種檢測(cè)法的一個(gè)重大的局限性。另外，為了能記錄內(nèi)存塊是在哪里分配的，源代碼必須相應(yīng)的配合，這在調(diào)試一些老的程序非常麻煩，畢竟修改源代碼不是一件省心的事，這是這種檢測(cè)法的另一個(gè)局限性。
對(duì)于開(kāi)發(fā)一個(gè)大型的程序，MS C-Runtime Library提供的檢測(cè)功能是遠(yuǎn)遠(yuǎn)不夠的。接下來(lái)我們就看看外掛式的檢測(cè)工具。我用的比較多的是BoundsChecker，一則因?yàn)樗墓δ鼙容^全面，更重要的是它的穩(wěn)定性。這類(lèi)工具如果不穩(wěn)定，反而會(huì)忙里添亂。到底是出自鼎鼎大名的NuMega，我用下來(lái)基本上沒(méi)有什么大問(wèn)題。
使用BoundsChecker檢測(cè)內(nèi)存泄漏：
BoundsChecker采用一種被稱(chēng)為 Code Injection的技術(shù)，來(lái)截獲對(duì)分配內(nèi)存和釋放內(nèi)存的函數(shù)的調(diào)用。簡(jiǎn)單地說(shuō)，當(dāng)你的程序開(kāi)始運(yùn)行時(shí)，BoundsChecker的DLL被自動(dòng)載入進(jìn)程的地址空間（這可以通過(guò)system-level的Hook實(shí)現(xiàn)），然后它會(huì)修改進(jìn)程中對(duì)內(nèi)存分配和釋放的函數(shù)調(diào)用，讓這些調(diào)用首先轉(zhuǎn)入它的代碼，然后再執(zhí)行原來(lái)的代碼。BoundsChecker在做這些動(dòng)作的時(shí)，無(wú)須修改被調(diào)試程序的源代碼或工程配置文件，這使得使用它非常的簡(jiǎn)便、直接。
這里我們以malloc函數(shù)為例，截獲其他的函數(shù)方法與此類(lèi)似。
需要被截獲的函數(shù)可能在DLL中，也可能在程序的代碼里。比如，如果靜態(tài)連結(jié)C-Runtime Library，那么malloc函數(shù)的代碼會(huì)被連結(jié)到程序里。為了截獲住對(duì)這類(lèi)函數(shù)的調(diào)用，BoundsChecker會(huì)動(dòng)態(tài)修改這些函數(shù)的指令。
以下兩段匯編代碼，一段沒(méi)有BoundsChecker介入，另一段則有BoundsChecker的介入：
126: _CRTIMP void * __cdecl malloc (
127: size_t nSize
128: )
129: {
00403C10 push ebp
00403C11 mov ebp,esp
130: return _nh_malloc_dbg(nSize, _newmode, _NORMAL_BLOCK, NULL, 0);
00403C13 push 0
00403C15 push 0
00403C17 push 1
00403C19 mov eax,[__newmode (0042376c)]
00403C1E push eax
00403C1F mov ecx,dword ptr [nSize]
00403C22 push ecx
00403C23 call _nh_malloc_dbg (00403c80)
00403C28 add esp,14h
131: } |
以下這一段代碼有BoundsChecker介入：
126: _CRTIMP void * __cdecl malloc (
127: size_t nSize
128: )
129: {
00403C10 jmp 01F41EC8
00403C15 push 0
00403C17 push 1
00403C19 mov eax,[__newmode (0042376c)]
00403C1E push eax
00403C1F mov ecx,dword ptr [nSize]
00403C22 push ecx
00403C23 call _nh_malloc_dbg (00403c80)
00403C28 add esp,14h
131: } |
當(dāng)BoundsChecker介入后，函數(shù)malloc的前三條匯編指令被替換成一條jmp指令，原來(lái)的三條指令被搬到地址01F41EC8處了。當(dāng)程序進(jìn)入malloc后先jmp到01F41EC8，執(zhí)行原來(lái)的三條指令，然后就是BoundsChecker的天下了。大致上它會(huì)先記錄函數(shù)的返回地址（函數(shù)的返回地址在stack上，所以很容易修改），然后把返回地址指向?qū)儆贐oundsChecker的代碼，接著跳到malloc函數(shù)原來(lái)的指令，也就是在00403c15的地方。當(dāng)malloc函數(shù)結(jié)束的時(shí)候，由于返回地址被修改，它會(huì)返回到BoundsChecker的代碼中，此時(shí)BoundsChecker會(huì)記錄由malloc分配的內(nèi)存的指針，然后再跳轉(zhuǎn)到到原來(lái)的返回地址去。
如果內(nèi)存分配/釋放函數(shù)在DLL中，BoundsChecker則采用另一種方法來(lái)截獲對(duì)這些函數(shù)的調(diào)用。BoundsChecker通過(guò)修改程序的DLL Import Table讓table中的函數(shù)地址指向自己的地址，以達(dá)到截獲的目的。
截獲住這些分配和釋放函數(shù)，BoundsChecker就能記錄被分配的內(nèi)存或資源的生命周期。接下來(lái)的問(wèn)題是如何與源代碼相關(guān)，也就是說(shuō)當(dāng)BoundsChecker檢測(cè)到內(nèi)存泄漏，它如何報(bào)告這塊內(nèi)存塊是哪段代碼分配的。答案是調(diào)試信息（Debug Information）。當(dāng)我們編譯一個(gè)Debug版的程序時(shí)，編譯器會(huì)把源代碼和二進(jìn)制代碼之間的對(duì)應(yīng)關(guān)系記錄下來(lái)，放到一個(gè)單獨(dú)的文件里(.pdb)或者直接連結(jié)進(jìn)目標(biāo)程序，通過(guò)直接讀取調(diào)試信息就能得到分配某塊內(nèi)存的源代碼在哪個(gè)文件，哪一行上。使用Code Injection和Debug Information，使BoundsChecker不但能記錄呼叫分配函數(shù)的源代碼的位置，而且還能記錄分配時(shí)的Call Stack，以及Call Stack上的函數(shù)的源代碼位置。這在使用像MFC這樣的類(lèi)庫(kù)時(shí)非常有用，以下我用一個(gè)例子來(lái)說(shuō)明：
void ShowXItemMenu()
{
…
CMenu menu;
menu.CreatePopupMenu();
//add menu items.
menu.TrackPropupMenu();
…
}
void ShowYItemMenu( )
{
…
CMenu menu;
menu.CreatePopupMenu();
//add menu items.
menu.TrackPropupMenu();
menu.Detach();//this will cause HMENU leak
…
}
BOOL CMenu::CreatePopupMenu()
{
…
hMenu = CreatePopupMenu();
…
} |
當(dāng)調(diào)用ShowYItemMenu()時(shí)，我們故意造成HMENU的泄漏。但是，對(duì)于BoundsChecker來(lái)說(shuō)被泄漏的HMENU是在class CMenu::CreatePopupMenu()中分配的。假設(shè)的你的程序有許多地方使用了CMenu的CreatePopupMenu()函數(shù)，如CMenu::CreatePopupMenu()造成的，你依然無(wú)法確認(rèn)問(wèn)題的根結(jié)到底在哪里，在ShowXItemMenu()中還是在ShowYItemMenu()中，或者還有其它的地方也使用了CreatePopupMenu()？有了Call Stack的信息，問(wèn)題就容易了。BoundsChecker會(huì)如下報(bào)告泄漏的HMENU的信息：
Function
File
Line
CMenu::CreatePopupMenu
E:\8168\vc98\mfc\mfc\include\afxwin1.inl
1009
ShowYItemMenu
E:\testmemleak\mytest.cpp
100 |
這里省略了其他的函數(shù)調(diào)用
如此，我們很容易找到發(fā)生問(wèn)題的函數(shù)是ShowYItemMenu()。當(dāng)使用MFC之類(lèi)的類(lèi)庫(kù)編程時(shí)，大部分的API調(diào)用都被封裝在類(lèi)庫(kù)的class里，有了Call Stack信息，我們就可以非常容易的追蹤到真正發(fā)生泄漏的代碼。
記錄Call Stack信息會(huì)使程序的運(yùn)行變得非常慢，因此默認(rèn)情況下BoundsChecker不會(huì)記錄Call Stack信息。可以按照以下的步驟打開(kāi)記錄Call Stack信息的選項(xiàng)開(kāi)關(guān)：
1. 打開(kāi)菜單：BoundsChecker|Setting…
2. 在Error Detection頁(yè)中，在Error Detection Scheme的List中選擇Custom
3. 在Category的Combox中選擇 Pointer and leak error check
4. 鉤上Report Call Stack復(fù)選框
5. 點(diǎn)擊Ok
基于Code Injection，BoundsChecker還提供了API Parameter的校驗(yàn)功能，memory over run等功能。這些功能對(duì)于程序的開(kāi)發(fā)都非常有益。由于這些內(nèi)容不屬于本文的主題，所以不在此詳述了。
盡管BoundsChecker的功能如此強(qiáng)大，但是面對(duì)隱式內(nèi)存泄漏仍然顯得蒼白無(wú)力。所以接下來(lái)我們看看如何用Performance Monitor檢測(cè)內(nèi)存泄漏。
使用Performance Monitor檢測(cè)內(nèi)存泄漏
NT的內(nèi)核在設(shè)計(jì)過(guò)程中已經(jīng)加入了系統(tǒng)監(jiān)視功能，比如CPU的使用率，內(nèi)存的使用情況，I/O操作的頻繁度等都作為一個(gè)個(gè)Counter，應(yīng)用程序可以通過(guò)讀取這些Counter了解整個(gè)系統(tǒng)的或者某個(gè)進(jìn)程的運(yùn)行狀況。Performance Monitor就是這樣一個(gè)應(yīng)用程序。
為了檢測(cè)內(nèi)存泄漏，我們一般可以監(jiān)視Process對(duì)象的Handle Count，Virutal Bytes 和Working Set三個(gè)Counter。Handle Count記錄了進(jìn)程當(dāng)前打開(kāi)的HANDLE的個(gè)數(shù)，監(jiān)視這個(gè)Counter有助于我們發(fā)現(xiàn)程序是否有Handle泄漏；Virtual Bytes記錄了該進(jìn)程當(dāng)前在虛地址空間上使用的虛擬內(nèi)存的大小，NT的內(nèi)存分配采用了兩步走的方法，首先，在虛地址空間上保留一段空間，這時(shí)操作系統(tǒng)并沒(méi)有分配物理內(nèi)存，只是保留了一段地址。然后，再提交這段空間，這時(shí)操作系統(tǒng)才會(huì)分配物理內(nèi)存。所以，Virtual Bytes一般總大于程序的Working Set。監(jiān)視Virutal Bytes可以幫助我們發(fā)現(xiàn)一些系統(tǒng)底層的問(wèn)題; Working Set記錄了操作系統(tǒng)為進(jìn)程已提交的內(nèi)存的總量，這個(gè)值和程序申請(qǐng)的內(nèi)存總量存在密切的關(guān)系，如果程序存在內(nèi)存的泄漏這個(gè)值會(huì)持續(xù)增加，但是Virtual Bytes卻是跳躍式增加的。
監(jiān)視這些Counter可以讓我們了解進(jìn)程使用內(nèi)存的情況，如果發(fā)生了泄漏，即使是隱式內(nèi)存泄漏，這些Counter的值也會(huì)持續(xù)增加。但是，我們知道有問(wèn)題卻不知道哪里有問(wèn)題，所以一般使用Performance Monitor來(lái)驗(yàn)證是否有內(nèi)存泄漏，而使用BoundsChecker來(lái)找到和解決。
當(dāng)Performance Monitor顯示有內(nèi)存泄漏，而B(niǎo)oundsChecker卻無(wú)法檢測(cè)到，這時(shí)有兩種可能：第一種，發(fā)生了偶發(fā)性?xún)?nèi)存泄漏。這時(shí)你要確保使用Performance Monitor和使用BoundsChecker時(shí)，程序的運(yùn)行環(huán)境和操作方法是一致的。第二種，發(fā)生了隱式的內(nèi)存泄漏。這時(shí)你要重新審查程序的設(shè)計(jì)，然后仔細(xì)研究Performance Monitor記錄的Counter的值的變化圖，分析其中的變化和程序運(yùn)行邏輯的關(guān)系，找到一些可能的原因。這是一個(gè)痛苦的過(guò)程，充滿(mǎn)了假設(shè)、猜想、驗(yàn)證、失敗，但這也是一個(gè)積累經(jīng)驗(yàn)的絕好機(jī)會(huì)。
總結(jié)
內(nèi)存泄漏是個(gè)大而復(fù)雜的問(wèn)題，即使是Java和.Net這樣有Gabarge Collection機(jī)制的環(huán)境，也存在著泄漏的可能，比如隱式內(nèi)存泄漏。由于篇幅和能力的限制，本文只能對(duì)這個(gè)主題做一個(gè)粗淺的研究。其他的問(wèn)題，比如多模塊下的泄漏檢測(cè)，如何在程序運(yùn)行時(shí)對(duì)內(nèi)存使用情況進(jìn)行分析等等，都是可以深入研究的題目。如果您有什么想法，建議或發(fā)現(xiàn)了某些錯(cuò)誤，歡迎和我交流。
http://dev.yesky.com/147/2356147_1.shtml