簡介: 前幾天發生了這樣一件事,我正在調試一個程序,這個程序用了一大堆亂七八糟的指針來處理一個鏈表,最終在一個指向鏈表結點的指針上出了問題。我們預計它應當指向的是一個虛基類的對象。我想到第一個問題是:指針所指的地方真的有一個對象嗎?出問題的指針值可以被4整除,并且不是NULL的,所以可以斷定它曾經是一個有效的指針。通過使用Visual Studio的內存查看窗口(View->Debug Windows->Memory)我們發現這個指針所指的數據是FE EE FE EE FE EE ...這通常意味著內存是曾經是被分配了的,但現在卻處于一種未分配的狀態。不知是誰、在什么地方把我的指針所指的內存區域給釋放掉了。我想要找出一種方案來查出我的數據到底是怎么會被釋放的。
代碼: 在經歷了幾次錯誤的猜測后,我決定求助于重載new和delete運算符來幫我找到我的指針所指向的數據。下面的new運算符的實現把返回地址從棧上提了出來。這個返回地址位于傳遞過來的參數和第一個局部變量的地址之間。編譯器的設置、調用函數的方法、計算機的體系結構都會引響到這個返回地址的實際位置,所以您在使用下面代碼的時候,要根據您的實際情況做一些調整。一旦new運算符獲得了返回地址,它就在將要實際分配的內存前面分配額外的16個字節的空間來存放這個返回地址和實際的分配的內存大小,并且把實際要分配的內存塊首地址返回。 對于delete運算符,你可以看到,它不再釋放空間。它用與new同樣的方法把返回地址提取出來,寫到實際分配空間大小的后面(譯者注:就是上面分配的16個字節的第9到第12個字節),在最后四個字節中填上DE AD BE EF(譯者注:四個十六進制數,當成單詞來看正好是dead beef,用來表示內存已釋放真是很形象?。?,并且把剩余的空間(譯者注:就是原本實際應該分配而現在應該要釋放掉的空間)都填上一個重復的值。 現在,假如程序由于一個錯誤的指針而出錯,我只需打開內存查看窗口,找到出錯的指針所指的地方,再往前找16個字節。這里的值就是調用new運算符的地址,接下來四個字節就是實際分配的內存大小,第三個四個字節是調用delete運算符的地址,最后四個字節應該是DE AD BE EF。接下的實際分配過的內存內容應該是77 77 77 77。 要通過這兩個返回地址在源程序中分別找到對應的new和delete,可以這樣做:首先把表示地址的四個字節的內容倒序排一下,這樣才能得到真正的地址,這里因為在Intel平臺上字節序是低位在前的。下一步,在源代碼上右擊點擊,選“Go To Diassembly”。在反匯編的窗口上的左邊一欄就是機器代碼對應的內存地址。按Ctrl + G或選擇Edit->Go To...并輸入你找到的地址之一。反匯編的窗口就將滾動到對應的new或delete的函數調用位置。要回到源程序只需再次右鍵單擊,選擇“Go To Source”。您就可以看到相應的new或delete的調用了。 更多內容請看C/C++技術專題專題,或 現在您就可以很方便的找出您的數據是何時丟失的了。至于要找出為什么delete會被調用,就要靠您自己了。 #include <MALLOC.H>
void * :perator new(size_t size)
{ int stackVar; unsigned long stackVarAddr = (unsigned long)&stackVar; unsigned long argAddr = (unsigned long)&size;