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