昨天晚上夢(mèng)見項(xiàng)目中解碼部分又出現(xiàn)了內(nèi)存泄露，今天到公司，小曲果然跟我說LogFileReader中存在內(nèi)存泄露問題（不過最后的結(jié)果是發(fā)生泄露的地方和夢(mèng)里的不一樣~：P）。
內(nèi)存泄露這個(gè)問題說大不大，可也不小。要是有那么點(diǎn)點(diǎn)泄露，你的程序又不要求長(zhǎng)期穩(wěn)定運(yùn)行，那也沒太大關(guān)系。不過我一向是以能夠長(zhǎng)期穩(wěn)定運(yùn)行來要求自己的程序的，所以就不得不干掉它，不然遲早要被它把內(nèi)存給吃干凈了。
VC6的環(huán)境中有一個(gè)好處，就是會(huì)有內(nèi)存泄露的提示。 形如：
Detected memory leaks!和Dumping objects ->我就不解釋了，不懂自己查詞典去。
后面的每一處內(nèi)存泄露的格式都是
{分配申請(qǐng)?zhí)杴 塊類型 at 首地址，大小 bytes long.
Data:< ASCII碼顯示的前16字節(jié)內(nèi)容 > 十六進(jìn)制顯示的前16字節(jié)內(nèi)容
幸運(yùn)的話，dbg信息中還有關(guān)于申請(qǐng)分配動(dòng)作所在的文件和行號(hào)的紀(jì)錄，那就會(huì)在上面的內(nèi)容之前顯示出來。那樣的話解決問題就容易多了。問題是如果你像我上面舉的例子那樣，沒有給出文件和行號(hào)，那你可就要費(fèi)點(diǎn)功夫咯。
我再來介紹一個(gè)技巧，上面講過內(nèi)存分配申請(qǐng)?zhí)柡褪椎刂穬蓚€(gè)很有用的信息，這兩個(gè)可以用來幫助你設(shè)置斷點(diǎn)。用地址為條件設(shè)置斷點(diǎn)，意圖在于當(dāng)分配了一塊內(nèi)存，其首地址剛好為我們?cè)O(shè)置的條件中的首地址的時(shí)候就中斷，我們接著跟蹤來探查是否存在內(nèi)存泄露（因?yàn)榉峙洹⑨尫诺木壒剩粋€(gè)地址可能會(huì)被使用很多次，所以要往下跟蹤探查），而以非配申請(qǐng)?zhí)枮橹袛鄺l件用意在于發(fā)生一個(gè)內(nèi)存分配，請(qǐng)求編號(hào)為我們?cè)O(shè)置的值時(shí)，就中斷。不過這兩招也會(huì)失靈，等會(huì)再說為什么。
以申請(qǐng)?zhí)枮橹袛鄺l件，你需要在程序啟動(dòng)的地方加入一行代碼
_crtBreakAlloc = xx;
或者是
_CrtSetBreakAlloc(xx);
其中的xx就是你要設(shè)置的申請(qǐng)?zhí)柫耍劣跁?huì)如何中斷，就留給看官自己去試驗(yàn)了。
以地址為條件呢，就繁瑣一點(diǎn)，你要先定位到你程序中用于分配的那個(gè)函數(shù)，比如VC6的MFC中debug的new就在X:\Program Files\Microsoft Visual Studio\VC98\MFC\SRC\AFXMEM.cpp中，找到函數(shù)的最后一個(gè)}設(shè)置條件斷點(diǎn)，條件是pResult == 首地址值，怎么設(shè)置斷點(diǎn)的條件？不用我教了吧，不會(huì)就自己去網(wǎng)上查吧。用這個(gè)辦法還能夠設(shè)置大小的條件中斷。不過呢，有個(gè)問題要注意，以new來說，不同的預(yù)編譯條件會(huì)導(dǎo)致它有幾條不同路線，其他的分配方式當(dāng)然也是有的，留著看官自己探索吧。
下面解釋一下這些方法為什么會(huì)失效，原因其實(shí)很簡(jiǎn)單，因?yàn)槊看芜\(yùn)行的時(shí)候這個(gè)申請(qǐng)編號(hào)和首地址都幾乎是變化的，所以你只有嘗試，如果這些值沒有變化，那就恭喜你，可能會(huì)發(fā)現(xiàn)問題了，要是變化了，可能你也就是竹籃打水一場(chǎng)空了。而如果是通過大小來設(shè)置條件斷點(diǎn)，你可能就能夠抓住問題，因?yàn)榘l(fā)生泄露的內(nèi)存大小一般都是不變的，而萬一這個(gè)大小太普通了，跟蹤100次才能找到問題所在也是可能的。:P
最后，再介紹點(diǎn)有用的，你有沒有發(fā)現(xiàn)MFC給你生成的cpp文件里面都有這么幾行：
#ifdef _DEBUG
#define new DEBUG_NEW
#undef THIS_FILE
static char THIS_FILE[] = __FILE__;
#endif
這幾行有什么用呢？如果發(fā)生內(nèi)存泄露的文件中有這幾行，那么，恭喜你，Output里面就會(huì)有文件名和行號(hào)了~至于為什么，呵呵，還是老話，留給看官研究吧。
基本上排查內(nèi)存泄露的方法技巧，我已經(jīng)知無不言了。可今天咱遇到的問題，卻沒那么好找，這工程里面基本上代碼都是別人寫的，而且文件還不少，前幾天幫忙她改的解碼文件就有差不多10萬行的代碼量，而且她那個(gè)解碼庫里面還用的是自己的內(nèi)存分配管理，上次就是查那個(gè)解碼庫中的內(nèi)存泄露整了我半天時(shí)間，昨天晚上那夢(mèng)不是沒理由的，我就擔(dān)心這里面出問題。不過還好，今天這問題不在這里面。
追查的過程我就不描述了，最后的原因倒是值得一提，為什么呢？因?yàn)樘摂M析構(gòu)函數(shù)的問題。NND！今天把老工程里面的一些代碼翻出來看，才發(fā)現(xiàn)問題大大的有，修改了好幾個(gè)類和內(nèi)存泄露相關(guān)的問題，相信有些是目前沒有暴露出來的，可那提示依然存在，我當(dāng)時(shí)也稀里糊涂的，我在子類的析構(gòu)函數(shù)中釋放的地方設(shè)置的斷點(diǎn)從來沒有斷下來過，我居然沒懷疑這個(gè)事情，唉，現(xiàn)在想起來就慚愧。最后我才注意到這個(gè)問題，前面搞什么條件中斷阿，什么分配申請(qǐng)?zhí)栔袛喟ⅲ诶速M(fèi)力氣。最后注意到的時(shí)候，都已經(jīng)流了不少汗了，這下想到析構(gòu)函數(shù)的virtual問題，子類的析構(gòu)函數(shù)倒是帶了“virtual”關(guān)鍵字，找到基類一看，NND，沒有構(gòu)造函數(shù)聲明，沒有析構(gòu)函數(shù)聲明，全部是默認(rèn)的，難怪進(jìn)不去。果然聲明一個(gè)空的虛擬析構(gòu)函數(shù)，問題就解決了，提示沒有了～５５５５５５早知道先把工程的每個(gè)ｃｐｐ文件中頭上加上那么一段，讓它給我定位出來再查問題了～