（轉）使用windbg檢測記憶體洩漏

阿新 • • 發佈：2019-01-21

轉載地址：

緣起：

作為C++程式設計師，檢測記憶體洩漏是非常痛苦的事情。尤其是看著程式的記憶體在一直增長，你卻無能為力。此時，windbg可以用來檢測記憶體洩漏。

配置windbg：

配置symbol檔案路徑： “SRV*d:\symbols*http://msdl.microsoft.com/download/symbols”.
增加測試程式test.exe的pdb 檔案到symbol檔案路徑
採用Gflags.exe，增加userstack trace到測試程式leak.exe中。 gflags.exe /i test.exe +ust

開始除錯：

1. 開啟windbg，點選’attach to process’，掛載上test.exe。

2. 敲入命令>!heap –s

NtGlobalFlag enables following debuggingaids for new heaps:

Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast

(k) (k) (k) (k) length blocks cont. heap

-----------------------------------------------------------------------------

02e90000 08000002 1024 408 1024 31 16 1 0 0 LFH

02e00000 08001002 1088 136 1088 18 4 2 0 0 LFH

04870000 08001002 256 20 256 1 2 1 0 0

00300000 08001002 3136 1308 3136 19 23 3 0 0 LFH

04840000 08001002 64 12 64 3 2 1 0 0

04750000 08001002 256 4 256 1 1 1 0 0

05740000 08001002 256 4 256 0 2 1 0 0

-----------------------------------------------------------------------------

3. 讓程式接著執行一段時間。。。

4. 再次輸入敲入命令>!heap –s

NtGlobalFlag enables following debuggingaids for new heaps:

Heap Flags Reserv Commit Virt Free List UCR Virt Lock Fast

(k) (k) (k) (k) length blocks cont. heap

-----------------------------------------------------------------------------

02e90000 08000002 1024 408 1024 32 16 1 0 0 LFH

02e00000 08001002 1088 136 1088 18 4 2 0 0 LFH

04870000 08001002 256 20 256 1 2 1 0 0

00300000 08001002 3136 1752 3136 14 23 3 0 0 LFH

04840000 08001002 64 12 64 3 2 1 0 0

04750000 08001002 256 4 256 1 1 1 0 0

05740000 08001002 256 4 256 0 2 1 0 0

-----------------------------------------------------------------------------

5. 比較兩次heap的分配情況，然後找出堆分配最多的heap，記住堆地址。

6. 輸入命令 0:015> !heap -stat -h 00300000

[email protected] 00300000

group-by: TOTSIZE max-display: 20

size #blocks total ( %) (percent of total busy bytes)

16a8 32 - 46cd0 (27.90)

800 85 - 42800 (26.20)

14 34dc - 42130 (26.03)

105b8 1 - 105b8 (6.44)

190 32 - 4e20 (1.92)

2012 2 - 4024 (1.58)

4000 1 - 4000 (1.58)

36b0 1 - 36b0 (1.35)

214 14 - 2990 (1.02)

7. 找到分配次數最多的記憶體堆，記住這個堆的大小，在這個例子中，我們找到分配次數是34dc，堆的大小是14.

8. 此時，輸入命令 0:015> !heap -flt s 14

_HEAP @ 2e90000

HEAP_ENTRY Size Prev Flags UserPtr UserSize - state

02eb33e0 0006 0000 [00] 02eb33f8 00014 - (busy)

mfc90u!CShellWrapper::`vftable'

02eb6ff0 0006 0006 [00] 02eb7008 00014 - (busy)

mfc90u!CShellWrapper::`vftable'

02eb83a8 0006 0006 [00] 02eb83c0 00014 - (busy)

…

9. 查詢任意一個分配該大小堆的地址，02eb7008

10. 輸入命令0:015> !heap -p -a 02eb7008

address 06aae780 found in

_HEAP @ 300000

HEAP_ENTRY Size Prev Flags UserPtr UserSize - state

06aae768 0006 0000 [00] 06aae780 00014 - (busy)

7719ddbd ntdll!RtlAllocateHeap+0x00000274

747c3a58 MSVCR90!malloc+0x00000079

460879 test!CUDPThread::Run+0x00000689

4601dc test!CUDPThread::Main+0x0000003c

74783433 MSVCR90!_callthreadstartex+0x0000001b

747834c7 MSVCR90!_threadstartex+0x00000069

11. 至此，我們可以定位程式中memory leak的函數了。

Issues：

1. Error: Symbol can not be found.

0:015> .reload /f 強制載入module

Reloading current modules

......

…

0:015> lm 檢視module載入情況

start end module name

741e0000 741e5000 wshtcpip (export symbols) C:\Windows\System32\wshtcpip.dll

741f0000 7422c000 mswsock (export symbols) C:\Windows\system32\mswsock.dll

74240000 74253000 dwmapi (export symbols) C:\Windows\system32\dwmapi.dll

74260000 742e0000 UxTheme (export symbols) C:\Windows\system32\UxTheme.dll

742e0000 742e9000 VERSION (export symbols) C:\Windows\system32\VERSION.dll

2. Heap – Invalid type information

0:015> !heap -s

*************************************************************************

*** Either you specified an unqualified symbol, or your debugger ***

*** doesn't have full symbol information. Unqualified symbol ***

*** resolution is turned off by default. Please either specify a ***

*** fully qualified symbol module!symbolname, or enable resolution ***

*** of unqualified symbols by typing ".symopt- 100". Notethat ***

*** enabling unqualified symbol resolution with network symbol ***

*** server shares in the symbol path may cause the debugger to ***

*** appear to hang for long periods of time when an incorrect ***

*** symbol name is typed or the network symbol server is down. ***

*** For some commands to work properly, your symbol path ***

*** must point to .pdb files that have full type information. ***

*** Certain .pdb files (such as the public OS symbols) do not ***

*** contain the required information. Contact the group that ***

*** provided you with these symbols if you need this command to ***

*** Type referenced: ntdll!_HEAP_ENTRY ***

*************************************************************************

Invalid type information

解決方法：

0:015> .symfix

0:015> .reload

Reloading current modules

.......................................

Ref：

（轉）使用windbg檢測記憶體洩漏

轉載地址：緣起：作為C++程式設計師，檢測記憶體洩漏是非常痛苦的事情。尤其是看著程式的記憶體在一直增長，你卻無能為力。此時，windbg可以用來檢測記憶體洩漏。配置windbg：配置symbol檔案路徑： “SRV*d:\symbols*http://msdl.micros

（轉）Oracle 11g記憶體分配分析(oracle 11g Memory Allocation Analysis)

開始用oracle11g有一段時間了，一直沒有整理Oracle記憶體方面的特點，尤其是在oracle11g裡面引入了 memory_max_target 和 memory_target之後，有了些新的變化和安排在memory方面； Oracle對記憶體的管理的優化從未間斷，

記憶體優化（二）如何避免記憶體洩漏

文章目錄一、不同生命週期導致的記憶體洩漏解決辦法二、非靜態內部類持有物件導致的記憶體洩漏 1. 非靜態內部類呼叫外部類的方法的 2. 內部類是如

JVM調優（8）Java的記憶體洩漏

記憶體溢位和記憶體洩漏記憶體溢位 out of memory，是指程式在申請記憶體時，沒有足夠的記憶體空間供其使用，出現out of memory；記憶體洩露 memory leak，是指程式在申請記憶體後，無法釋放已申請的記憶體空間，一次記憶體洩露危害可以忽略，但記憶體洩露

（轉）Linux共享記憶體使用常見陷阱與分析(4)-共享記憶體刪除的陷阱

轉自http://os.51cto.com/art/201311/418977_3.htm 共享記憶體刪除的陷阱？當程序結束使用共享記憶體區時，要通過函式 shmdt 斷開與共享記憶體區的連線。該函式宣告在 sys/shm.h 中，其原型如下： #include #

（轉）Linux共享記憶體使用常見陷阱與分析(3)-ftok是否一定會產生唯一的key值

轉自http://os.51cto.com/art/201311/418977_2.htm ftok是否一定會產生唯一的key值？系統建立IPC通訊（如訊息佇列、共享記憶體時）必須指定一個ID值。通常情況下，該id值通過ftok函式得到。 ftok原型如下： ke

（轉）基類解構函式必須為虛擬函式否則會造成記憶體洩漏

看看下面程式有什麼錯誤： #include <iostream> using namespace std; class Father { public: Father(){}; ~Father(){}; }; class Son:public

（轉）Context記憶體洩漏問題

今天看了一篇介紹Context的文章，寫的不錯，裡面有一段內容平時開發時候沒有注意到，摘抄如下：在專案中，我們經常會遇到使用單例模式或者靜態static變數，雖然使用靜態類或者靜態變數很方便，但是也潛在很多的記憶體洩漏問題。 6.1靜態資源導致的記憶體洩漏

Java靜態檢測工具/Java代碼規範和質量檢查簡單介紹（轉）

pub 詳細職責 web 循環問題：集成死鎖參考靜態檢查：靜態測試包括代碼檢查、靜態結構分析、代碼質量度量等。它可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟件工具自動進行。代碼檢查代碼檢查包括代碼走查、桌面檢查、代碼審查等，主要檢查代碼和設計的一致

Harris角點及Shi-Tomasi角點檢測（轉）

wid fast 進度 -cp 成了 out gif 角點檢測自定義一、角點定義有定義角點的幾段話： 1、角點檢測(Corner Detection)是計算機視覺系統中用來獲得圖像特征的一種方法，廣泛應用於運動檢測、圖像匹配、視頻跟蹤、三維建模和目標識別等領域中。也

python+opencv+EAST做自然場景文字檢測（轉）

mark一下，感謝作者分享！ https://blog.csdn.net/luolan9611/article/details/81914251 英文原文連結：https://www.pyimagesearch.

C語言記憶體分配及堆疊問題總結（轉）

結構體（或者聯合體）變數的成員在記憶體裡是如何分佈的（轉）

1、概述結構體變數的成員在記憶體裡是如何分佈的、成員先後順序始怎樣的、成員之間是連續的還是分散的、還是其他的什麼形式？這些問題既和軟體相關又和硬體相關。所謂軟體相關主要是指和具體的程式語言的編譯器的特性相關，編譯器為了優化CPU訪問記憶體的效率，在生成結構體成員的起始地址時遵循著某種特定的規則，這就是所謂

再有人問你Java記憶體模型是什麼，就把這篇文章發給他。（轉）

原文連結：再有人問你Java記憶體模型是什麼，就把這篇文章發給他。前幾天，發了一篇文章，介紹了一下JVM記憶體結構、Java記憶體模型以及Java物件模型之間的區別。有很多小夥伴反饋希望可以深入的講解下每個知識點。Java記憶體模型，是這三個知識點當中最晦澀難懂的一個，而且涉及到很多背

（Android Studio 3.0）Android Profiler記憶體洩漏檢查

前提概要記憶體洩漏是常見又重要的問題，針對這個問題谷歌在Android Studio 3.0中推出了Android Profiler。筆者此篇文章主要記錄一下Android Profiler在記憶體洩漏方面的使用。 Android Profiler Android

windows記憶體結構概述（轉）

13.1 Windows的虛擬地址空間安排 13.1.1虛擬地址空間的分割槽（即虛擬地址空間佈局）程序的地址空間劃分分割槽 x86 32位 Windows 3GB使用者模式下的x86

7 More Effective C++—條款10（建構函式內阻止記憶體洩漏）

1 提出問題上一篇文章中，我們討論瞭如下情況，當函式doSomething()被呼叫時，heap中資源無法被釋放，導致記憶體洩漏問題發生。 void function() { MyObject *object = new MyObject; object-

Windbg實用手冊（轉）

Windbg工作中用的不多，所以命令老是記不住，每次使用都要重新查命令，挺煩。趁這次培訓的機會好好測試和總結了一下，下次再用就方便多了。在這裡一起共享一下，如果有錯誤，請指正。基本知識和常用命令安裝完後執行windbg –I將Windbg設定成預設偵錯程式

Linux原始碼解析-記憶體描述符（mm_struct）（轉）

轉自 1.簡介一個程序的虛擬地址空間主要由兩個資料結構來描述。一個是最高層次的：mm_struct（定義在mm_types.h中），一個是較高層次的：vm_area_structs。最高層次的mm_struct結構描述了一個程序的整個虛擬地址空間。較高層次的結構vm

Excel 4.0巨集躲避殺軟檢測（轉）

復現環境： Windows 7 x64 復現程式： Office 2016 Excel Office 2013 Excel 影響程式：全版本參考文章： https://mp.weixin.qq.com/s/KVpO02KJWE6OVZDb0ungOA https://outflank.n

（轉）使用windbg檢測記憶體洩漏

相關推薦