在大型專案中，記憶體洩露並不會立即
crash
，會使系統效能不斷下降，甚至因記憶體耗盡而崩潰。排查起來難度也比較大，申請記憶體的地方很多。這裡介紹的這種方法可以迅速定位問題。
下面的程式crash64，每秒會申請1m的記憶體，而一直都沒有釋放，產生記憶體洩露
windbg 中有個小工具 umdh可以追蹤系統每個程序堆分配和釋放的過程，通過分析比較能夠對比出哪一次分配的堆空間沒有釋放。
開啟堆資訊追蹤 ，命令如下
gflags /i imagename +ust
magename表示程序名字
這裡輸入gflags /i crash64.exe +ust
通過設定環境變數_nt_symbol_path，umdh可以找對應的pdb符號檔案
這裡的符號檔案包括兩部分，
一是系統的，例如ntdll,msvcr100, kernel32等等
二是我們程式的
因此我配置的環境變數如下
srv*c:\symbols*
這樣配置就完成了 可以開始分析了
這時再次執行crash64.exe ,開啟pe 找到pid 為4800
cmd中輸入umdh -p:4800 -f:d:\crash64old.log
此時儲存了乙個日誌檔案到d盤
等一段時間 觀察pe的記憶體趨勢圖，感覺發生了記憶體洩露後 我這個是每秒鐘都會發生一次記憶體洩露 所以不用看pe了
再次輸入 umdh -p:4800-f:d:\crash64new.log
d:\crash64old.log d:\crash64new.log 名字都是可以隨便起的
又儲存了乙個日誌到d盤
現在輸入umdh -d d:\crash64old.logd:\crash64new.log > d:\crash64.txt
umdh就開始比較這兩個日誌檔案了 並將比較的結果存在
crash64.txt中
注意這裡的檔名需要是絕對路徑 不然就定位到systerm32目錄中去了上面我就搞錯了次
這時開啟crash64.txt
+ 234873856 ( 350213696 - 115339840) 334 allocs backtrace75d00
+ 224 ( 334 - 110) backtrace75d00 allocations
ntdll!?? ::fnodobfm::`string'+0001913b
msvcr100!malloc+0000005b
msvcr100!operatornew+0000001f
crash64!wmain+00000036(d:\sample\crash64\crash64\crash64.cpp, 16)
crash64!__tmaincrtstartup+0000011a(f:\dd\vctools\crt_bld\self_64_amd64\crt\src\crtexe.c, 552)
kernel32!basethreadinitthunk+0000000d
ntdll!rtluserthreadstart+0000001d
total increase == 234873856 requested+ 7168 overhead = 234881024
結果出來拉
+234873856表示增加的記憶體位元組
+224表示增加申請的次數
234873856 /224 = 1,048,544 = 1024 * 1023 跟**中實際現象一樣
（怎麼不是1024 *1024 是1024*1023？）
申請的位置在crash64.cpp中的16行
正是 這句 p =
newchar
[1024 * 1024];
windbg除錯 控制代碼洩露
1 用c 寫乙個控制代碼洩露的樣例程式 include stdafx.h include void fun1 void void fun2 void void fun3 void void fun4 void int main int argc,char argv return 0 void fun...
DEBUG 記憶體洩露除錯
呼。又是一次痛苦的除錯經歷，趕緊記點心得吧。雖然是乙個很傻x的失誤，但是經歷的過程還是收穫蠻多的。開始之前，順便透露一下，關於shero，我已經決定做乙個單機開源rpg了，最遲在5月發布吧，最終效果相信不會令大家失望。好了，起因是這樣的，因為整合了cegui，介面基本搭好時，卻發現有嚴重的記憶體洩露...
iOS SN Xcode記憶體洩露除錯
用xcode進行記憶體除錯有兩種方法 1 靜態方法 2 動態方法 靜態方法是直接在xcode的選單欄中選擇product analyze 如截圖所示。提示有可能有多少洩露物件，這裡還沒有編譯完，提示有199個，然後再如下圖所示 就會看到具體的提示，有的提示會有潛在的洩露物件，有的提示垃圾物件，或者值...