小木發(fā)現(xiàn)線上的程序通過任務管理器發(fā)現(xiàn)內(nèi)存不斷的增長，懷疑是不是內(nèi)存泄漏呢？用戶態(tài)內(nèi)存泄漏可能是句柄泄漏，堆內(nèi)存泄露，Socket,?GDI對象等等。而對于C 程序員來說，碰到最多的無疑是堆內(nèi)存泄露：也就是通過malloc或者new從堆上申請的內(nèi)存，使用完成后，并沒有釋放，導致程序使用的內(nèi)存越來越多。

小木找到了一個分析利器UMDH: 這也是Windbg工具集中的其中一個利器，它可以在一個時間點記錄程序的當前程序使用的堆內(nèi)存申請的信息，過一段時間后再記錄一次程序使用的堆內(nèi)存申請的信息，然后比較兩次的結(jié)果來找到這段時間內(nèi)增加的堆內(nèi)存及其關(guān)聯(lián)的函數(shù)調(diào)用棧，從而查找內(nèi)存泄露。為了分析問題，小木先嘗試著寫了以下測試程序, 熟悉下工具的使用。程序每隔十秒鐘調(diào)用一次MemorLeakFunction?，在函數(shù)中每次會從堆上申請一段內(nèi)存空間，并且沒有釋放。

#include #include #include
void MemoryLeakFunction(){ const int STR_SIZE = 100; char * pStr = new char [STR_SIZE]; strcpy_s(pStr, STR_SIZE, "收起Memory Leak Sample"); std::cout << pStr << std::endl;}
int main(){ while (true) { MemoryLeakFunction(); std::this_thread::sleep_for(std::chrono::seconds(10)); } return 0;}第一步小木先使用gflag(這個也是Windbg工具集中的一個重要工具，主要用于修改系統(tǒng)的配置來達到調(diào)試的目的)。以下命令可以對MemoryLeak.exe程序申請堆上內(nèi)存的時候記錄其函數(shù)調(diào)用棧。
"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\gflags" -i MemoryLeak.exe ust。直接運行gflags圖形化界面打開如下圖, 開啟Create user mode stack trace database

第二步?運行測試程序MemoryLeak.exe

第三步?將你程序的symbol文件MemoryLeak.pdb拷貝到mysymbols目錄下。運行命令配置Symbol：Set _NT_SYMBOL_PATH=C:\mysymbols;SRV*C:\symbols*http://msdl.microsoft.com/download/symbols

第四步?保存當前程序申請內(nèi)存的記錄，相當于做一個堆內(nèi)存申請的Snapshot，并且將結(jié)果導入到C:\umdhlog\begin.log。運行命令(需要一些時間，請耐心等待哦)"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\umdh" -pn:MemoryLeak.exe -f:C:\umdhlog\begin.log

第五步?等程序運行一段時間后。這個等待的時間根據(jù)程序內(nèi)存泄露的快慢來自行決定，要有足夠的時間，來表現(xiàn)出程序使用堆上內(nèi)存的差異。假設這里等待5分鐘左右，再次運行如下命令,將結(jié)果導入到C:\undhlog\end.log中:?"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\umdh" -pn:MemoryLeak.exe -f:C:\umdhlog\end.log

第六步?最后一步來比較end.log和begin.log內(nèi)存申請的差異，來找到這段時間內(nèi)增加的堆內(nèi)存請求調(diào)用棧,并且導入到c:\umdhlog\diff.log。運行命令(有時候運行比較長，可以利用這段時間思考下人生吧):"C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\umdh" C:\umdhlog\begin.log C:\umdhlog\end.log -f:c:\umdhlog\diff.log

最后一步?diff.log中可以看到增加的內(nèi)存申請的函數(shù)調(diào)用棧，比如這段

1194 ( 157c - 3e8) 37 allocs BackTrace1 2d ( 37 - a) BackTrace1 allocations
ntdll!RtlpAllocateHeap 2122 ntdll!RtlpAllocateHeapInternal 5E5 ucrtbase!_malloc_base 36 MemoryLeak!operator new 1F (d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\heap\new_scalar.cpp, 35) MemoryLeak!main 2D (c:\personal\git\beyourbest\cpp\windbgsample\memoryleak\memoryleaksample.cpp, 17) MemoryLeak!__scrt_common_main_seh 10C (d:\agent\_work\2\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl, 288) KERNEL32!BaseThreadInitThunk 14 ntdll!RtlUserThreadStart 21注意里面默認采用的是16進制表示的數(shù)量，比如0x1194表示在umdh比較的兩個時間段之間，這段函數(shù)調(diào)用棧申請了4500個字節(jié)的堆空間，0x2d表示這之間調(diào)用了45次。最關(guān)鍵的部分就是函數(shù)調(diào)用棧了,里面指明了在memoryleaksample.cpp文件的第17行進行了內(nèi)存申請。這個時候我們一般對這段代碼進行審查，都能夠找出內(nèi)存泄露的原因，比如這里的例子，使用后未釋放內(nèi)存。

在熟悉了UMDH的使用后，對線上出現(xiàn)的實際問題進行分析，也很快找到了內(nèi)存泄露原因。

發(fā)送關(guān)鍵字?內(nèi)存泄漏 獲取內(nèi)存泄漏系列文章

- EOF -