一、mtrace分析內(nèi)存泄露

mtrace（memory trace），是 GNU Glibc 自帶的內(nèi)存問(wèn)題檢測(cè)工具，它可以用來(lái)協(xié)助定位內(nèi)存泄露問(wèn)題。它的實(shí)現(xiàn)源碼在glibc源碼的malloc目錄下，其基本設(shè)計(jì)原理為設(shè)計(jì)一個(gè)函數(shù) void mtrace ()，函數(shù)對(duì) libc 庫(kù)中的 malloc/free 等函數(shù)的調(diào)用進(jìn)行追蹤，由此來(lái)檢測(cè)內(nèi)存是否存在泄漏的情況。mtrace是一個(gè)C函數(shù)，在<mcheck.h>里聲明及定義，函數(shù)原型為：

mtrace原理

mtrace()?函數(shù)會(huì)為那些和動(dòng)態(tài)內(nèi)存分配有關(guān)的函數(shù)（譬如 malloc()、realloc()、memalign() 以及 free()）安裝 “鉤子（hook）” 函數(shù)，這些 hook 函數(shù)會(huì)為我們記錄所有有關(guān)內(nèi)存分配和釋放的跟蹤信息，而 muntrace() 則會(huì)卸載相應(yīng)的 hook 函數(shù)。

基于這些 hook 函數(shù)生成的調(diào)試跟蹤信息，我們就可以分析是否存在 “內(nèi)存泄露” 這類問(wèn)題了。

設(shè)置日志生成路徑

mtrace 機(jī)制需要我們實(shí)際運(yùn)行一下程序，然后才能生成跟蹤的日志，但在實(shí)際運(yùn)行程序之前還有一件要做的事情是需要告訴 mtrace （即前文提到的 hook 函數(shù)）生成日志文件的路徑。

設(shè)置日志生成路徑有兩種，一種是設(shè)置環(huán)境變量：export MALLOC_TRACE=./test.log // 當(dāng)前目錄下?另一種是在代碼層面設(shè)置：setenv("MALLOC_TRACE", "output_file_name", 1);``output_file_name就是儲(chǔ)存檢測(cè)結(jié)果的文件的名稱。

測(cè)試實(shí)例

從上述代碼中，我們希望能夠在程序開始到結(jié)束檢查內(nèi)存是否泄漏的問(wèn)題，例子簡(jiǎn)單，一眼就能看出存在內(nèi)存泄漏的問(wèn)題，所以我們需要驗(yàn)證 mtrace 是否能夠檢查出來(lái)內(nèi)存泄漏問(wèn)題，且檢查的結(jié)果如何分析定位。?gcc -g test.c -o test生成可執(zhí)行文件。

日志

程序運(yùn)行結(jié)束，會(huì)在當(dāng)前目錄生成 test.log 文件，打開可以看到一下內(nèi)容：

從這個(gè)文件中可以看出中間三行分別對(duì)應(yīng)源碼中的 malloc -> free -> malloc 操作。解讀：./test 指的是我們執(zhí)行的程序名字，[0x400624] 是第一次調(diào)用 malloc 函數(shù)機(jī)器碼中的地址信息，+ 表示申請(qǐng)內(nèi)存（ - 表示釋放），0x21ed450 是 malloc 函數(shù)申請(qǐng)到的地址信息，0x64 表示的是申請(qǐng)的內(nèi)存大小。由此分析第一次申請(qǐng)已經(jīng)釋放，第二次申請(qǐng)沒(méi)有釋放，存在內(nèi)存泄漏的問(wèn)題。

泄露分析

使用addr2line工具定位源碼位置

通過(guò)使用 "addr2line" 命令工具，得到源文件的行數(shù)（通過(guò)這個(gè)可以根據(jù)機(jī)器碼地址定位到具體源碼位置）

使用mtrace工具分析日志信息

mtrace + 可執(zhí)行文件路徑 + 日志文件路徑?mtrace test ./test.log執(zhí)行，輸出如下信息：

二、Valgrind分析內(nèi)存泄露

Valgrind工具介紹

Valgrind是一套Linux下，開放源代碼（GPL V2）的仿真調(diào)試工具的集合。Valgrind由內(nèi)核（core）以及基于內(nèi)核的其他調(diào)試工具組成。內(nèi)核類似于一個(gè)框架（framework），它模擬了一個(gè)CPU環(huán)境，并提供服務(wù)給其他工具；而其他工具則類似于插件 (plug-in)，利用內(nèi)核提供的服務(wù)完成各種特定的內(nèi)存調(diào)試任務(wù)。Valgrind的體系結(jié)構(gòu)如下圖所示

1、Memcheck

最常用的工具，用來(lái)檢測(cè)程序中出現(xiàn)的內(nèi)存問(wèn)題，所有對(duì)內(nèi)存的讀寫都會(huì)被檢測(cè)到，一切對(duì)malloc() / free() / new / delete 的調(diào)用都會(huì)被捕獲。

所以，它能檢測(cè)以下問(wèn)題：對(duì)未初始化內(nèi)存的使用；讀/寫釋放后的內(nèi)存塊；讀/寫超出malloc分配的內(nèi)存塊；讀/寫不適當(dāng)?shù)臈Ｖ袃?nèi)存塊；內(nèi)存泄漏，指向一塊內(nèi)存的指針永遠(yuǎn)丟失；不正確的malloc/free或new/delete匹配；memcpy()相關(guān)函數(shù)中的dst和src指針重疊。

2、Callgrind

和 gprof 類似的分析工具，但它對(duì)程序的運(yùn)行觀察更是入微，能給我們提供更多的信息。和 gprof 不同，它不需要在編譯源代碼時(shí)附加特殊選項(xiàng)，但加上調(diào)試選項(xiàng)是推薦的。

Callgrind 收集程序運(yùn)行時(shí)的一些數(shù)據(jù)，建立函數(shù)調(diào)用關(guān)系圖，還可以有選擇地進(jìn)行 cache 模擬。在運(yùn)行結(jié)束時(shí)，它會(huì)把分析數(shù)據(jù)寫入一個(gè)文件。callgrind_annotate 可以把這個(gè)文件的內(nèi)容轉(zhuǎn)化成可讀的形式。

3、Cachegrind

Cache 分析器，它模擬 CPU 中的一級(jí)緩存 I1，Dl 和二級(jí)緩存，能夠精確地指出程序中 cache 的丟失和命中。如果需要，它還能夠?yàn)槲覀兲峁?cache 丟失次數(shù)，內(nèi)存引用次數(shù)，以及每行代碼，每個(gè)函數(shù)，每個(gè)模塊，整個(gè)程序產(chǎn)生的指令數(shù)。這對(duì)優(yōu)化程序有很大的幫助。

4、Helgrind

它主要用來(lái)檢查多線程程序中出現(xiàn)的競(jìng)爭(zhēng)問(wèn)題。Helgrind 尋找內(nèi)存中被多個(gè)線程訪問(wèn)，而又沒(méi)有一貫加鎖的區(qū)域，這些區(qū)域往往是線程之間失去同步的地方，而且會(huì)導(dǎo)致難以發(fā)掘的錯(cuò)誤。

Helgrind 實(shí)現(xiàn)了名為“Eraser”的競(jìng)爭(zhēng)檢測(cè)算法，并做了進(jìn)一步改進(jìn)，減少了報(bào)告錯(cuò)誤的次數(shù)。不過(guò)，Helgrind 仍然處于實(shí)驗(yàn)階段。

5、Massif

堆棧分析器，它能測(cè)量程序在堆棧中使用了多少內(nèi)存，告訴我們堆塊，堆管理塊和棧的大小。

Massif 能幫助我們減少內(nèi)存的使用，在帶有虛擬內(nèi)存的現(xiàn)代系統(tǒng)中，它還能夠加速我們程序的運(yùn)行，減少程序停留在交換區(qū)中的幾率。

此外，lackey 和 nulgrind 也會(huì)提供。Lackey 是小型工具，很少用到；Nulgrind 只是為開發(fā)者展示如何創(chuàng)建一個(gè)工具。

Memcheck原理

本文的重點(diǎn)是在檢測(cè)內(nèi)存泄露，所以對(duì)于valgrind的其他工具不做過(guò)多的說(shuō)明，主要說(shuō)明下Memcheck的工作。Memcheck檢測(cè)內(nèi)存問(wèn)題的原理如下圖所示：

Memcheck 能夠檢測(cè)出內(nèi)存問(wèn)題，關(guān)鍵在于其建立了兩個(gè)全局表。

• Valid-Value 表 對(duì)于進(jìn)程整個(gè)地址空間中的每一個(gè)字節(jié)(byte)，都有與之對(duì)應(yīng)的 8個(gè)bits；對(duì)于 CPU 的每個(gè)寄存器，也有一個(gè)與之對(duì)應(yīng)的 bit 向量。這些 bits 負(fù)責(zé)記錄該字節(jié)或者寄存器值是否具有有效的、已初始化的值。

• Valid-Address 表 對(duì)于進(jìn)程整個(gè)地址空間中的每一個(gè)字節(jié)(byte)，還有與之對(duì)應(yīng)的1個(gè) bit，負(fù)責(zé)記錄該地址是否能夠被讀寫。

• 檢測(cè)原理：當(dāng)要讀寫內(nèi)存中某個(gè)字節(jié)時(shí)，首先檢查這個(gè)字節(jié)對(duì)應(yīng)的Valid-Address 表中的 A bit。如果該 A bit顯示該位置是無(wú)效位置，memcheck 則報(bào)告讀寫錯(cuò)誤。內(nèi)核（core）類似于一個(gè)虛擬的 CPU 環(huán)境，這樣當(dāng)內(nèi)存中的某個(gè)字節(jié)被加載到真實(shí)的 CPU 中時(shí)，該字節(jié)對(duì)應(yīng)的Valid-Value 表中的 V bit 也被加載到虛擬的 CPU 環(huán)境中。一旦寄存器中的值，被用來(lái)產(chǎn)生內(nèi)存地址，或者該值能夠影響程序輸出，則 memcheck 會(huì)檢查對(duì)應(yīng)的V bits，如果該值尚未初始化，則會(huì)報(bào)告使用未初始化內(nèi)存錯(cuò)誤。

內(nèi)存泄露類型

valgrind 將內(nèi)存泄漏分成 4 類：

• 確立泄露（definitely lost）：運(yùn)行內(nèi)存還沒(méi)有釋放出來(lái)，但早已沒(méi)有表針偏向運(yùn)行內(nèi)存，運(yùn)行內(nèi)存早已不能瀏覽。確立泄露的運(yùn)行內(nèi)存是強(qiáng)烈要求修補(bǔ)的。

• 間接性泄露（indirectly lost）：泄露的運(yùn)行內(nèi)存表針儲(chǔ)存在確立泄露的運(yùn)行內(nèi)存中，伴隨著確立泄露的運(yùn)行內(nèi)存不能瀏覽，造成間接性泄露的運(yùn)行內(nèi)存也不能瀏覽。例如：

這里遺失的是 root 表針（是確立泄露類型），造成 root 儲(chǔ)存的 next 表針變成了間接性泄露。間接性泄露的運(yùn)行內(nèi)存毫無(wú)疑問(wèn)也要修補(bǔ)的，但是一般會(huì)伴隨著 確立泄露 的修補(bǔ)而修補(bǔ)。

• 很有可能泄露（possibly lost）：表針并不偏向運(yùn)行內(nèi)存頭詳細(xì)地址，只是偏向運(yùn)行內(nèi)存內(nèi)部的部位。valgrind 往往會(huì)猜疑很有可能泄露，是由于表針早已偏位，并沒(méi)有偏向運(yùn)行內(nèi)存頭，只是有運(yùn)行內(nèi)存偏位，偏向運(yùn)行內(nèi)存內(nèi)部的部位。有一些情況下，這并并不是泄露，由于這種程序流程便是那么設(shè)計(jì)方案的，比如為了更好地完成內(nèi)存對(duì)齊，附加申請(qǐng)辦理運(yùn)行內(nèi)存，回到兩端對(duì)齊后的內(nèi)存地址。

• 仍可訪達(dá)（still reachable）：表針一直存有且偏向運(yùn)行內(nèi)存頭頂部，直到程序流程撤出時(shí)運(yùn)行內(nèi)存還沒(méi)有釋放出來(lái)。

【文章福利】小編推薦自己的Linux內(nèi)核技術(shù)交流群:【749907784】整理了一些個(gè)人覺(jué)得比較好的學(xué)習(xí)書籍、視頻資料共享在群文件里面，有需要的可以自行添加哦?。。。ê曨l教程、電子書、實(shí)戰(zhàn)項(xiàng)目及代碼)? ? ? ?

Valgrind參數(shù)設(shè)置

• --leak-check=<no|summary|yes|full> 如果設(shè)為 yes 或 full，在被調(diào)程序結(jié)束后，valgrind 會(huì)詳細(xì)敘述每一個(gè)內(nèi)存泄露情況 默認(rèn)是summary，只報(bào)道發(fā)生了幾次內(nèi)存泄露

• --log-fd=?[default: 2, stderr] valgrind 打印日志轉(zhuǎn)存到指定文件或者文件描述符。如果沒(méi)有這個(gè)參數(shù)，valgrind 的日志會(huì)連同用戶程序的日志一起輸出，會(huì)顯得非常亂。

• --trace-children=<yes | no> [default: no] 是否跟蹤子進(jìn)程，若是多進(jìn)程的程序，則建議使用這個(gè)功能。不過(guò)單進(jìn)程使能了也不會(huì)有多大影響。

• --keep-debuginfo=<yes | no> [default: no] 如果程序有使用 動(dòng)態(tài)加載庫(kù)（dlopen），在動(dòng)態(tài)庫(kù)卸載時(shí)（dlclose），debug信息都會(huì)被清除。使能這個(gè)選項(xiàng)后，即使動(dòng)態(tài)庫(kù)被卸載，也會(huì)保留調(diào)用棧信息。

• --keep-stacktraces=<alloc | free | alloc-and-free | alloc-then-free | none> [default: alloc-and-free] 內(nèi)存泄漏不外乎申請(qǐng)和釋放不配對(duì)，函數(shù)調(diào)用棧是只在申請(qǐng)時(shí)記錄，還是在申請(qǐng)釋放時(shí)都記錄 如果我們只關(guān)注內(nèi)存泄漏，其實(shí)完全沒(méi)必要申請(qǐng)釋放都記錄，因?yàn)檫@會(huì)占用非常多的額外內(nèi)存和更多的 CPU 損耗，讓本來(lái)就執(zhí)行慢的程序雪上加霜。

• --freelist-vol=?當(dāng)客戶程序用 free 或 delete 釋放一個(gè)內(nèi)存塊時(shí)，這個(gè)內(nèi)存塊不會(huì)立即可用于再分配，它只會(huì)被放在一個(gè)freed blocks的隊(duì)列中（freelist）并被標(biāo)記為不可訪問(wèn)，這樣有利于探測(cè)到在一段很重要的時(shí)間后，客戶程序又對(duì)被釋放的塊進(jìn)行訪問(wèn)的錯(cuò)誤。這個(gè)選項(xiàng)規(guī)定了隊(duì)列所占的字節(jié)塊大小，默認(rèn)是20MB。增大這個(gè)選項(xiàng)的會(huì)增大memcheck的內(nèi)存開銷，但查這類錯(cuò)的能力也會(huì)提升。

• --freelist-big-blocks=?當(dāng)從 freelist 隊(duì)列中取可用內(nèi)存塊用于再分配時(shí)，memcheck 將會(huì)從那些比 number 大的內(nèi)存塊中按優(yōu)先級(jí)取出一個(gè)塊出來(lái)用。這個(gè)選項(xiàng)就防止了 freelist 中那些小的內(nèi)存塊的頻繁調(diào)用，這個(gè)選項(xiàng)提高了 查到針對(duì)小內(nèi)存塊的野指針錯(cuò)誤的幾率。若這個(gè)選項(xiàng)設(shè)為0，則所有的塊將按先進(jìn)先出的原則用于再分配。默認(rèn)是1M。參考：valgrind 簡(jiǎn)介(內(nèi)存檢查工具)

編譯參數(shù)推薦

為了更好地在出難題時(shí)要詳盡打印出出去棧信息內(nèi)容，實(shí)際上大家最好是在編譯程序時(shí)加上 -g 選擇項(xiàng)。如果有動(dòng)態(tài)性載入的庫(kù)，必須再加上?--keep-debuginfo=yes?，不然假如發(fā)覺(jué)是動(dòng)態(tài)性載入的庫(kù)發(fā)生泄露，因?yàn)閯?dòng)態(tài)庫(kù)被卸載掉了，造成找不到符號(hào)表。編碼編譯程序提升，不建議應(yīng)用 -O2既之上。-O0很有可能會(huì)造成運(yùn)作變慢，建議使用-O1。

檢測(cè)實(shí)例說(shuō)明

申請(qǐng)不釋放內(nèi)存

使用valgrind命令來(lái)執(zhí)行程序同時(shí)輸出日志到文件

參數(shù)說(shuō)明：

• –log-file=valReport 是指定生成分析日志文件到當(dāng)前執(zhí)行目錄中，文件名為valReport

• –leak-check=full 顯示每個(gè)泄露的詳細(xì)信息

• –show-reachable=yes 是否檢測(cè)控制范圍之外的泄漏，比如全局指針、static指針等，顯示所有的內(nèi)存泄露類型

• –leak-resolution=low 內(nèi)存泄漏報(bào)告合并等級(jí)

• –track-origins=yes表示開啟“使用未初始化的內(nèi)存”的檢測(cè)功能，并打開詳細(xì)結(jié)果。如果沒(méi)有這句話，默認(rèn)也會(huì)做這方面的檢測(cè)，但不會(huì)打印詳細(xì)結(jié)果。執(zhí)行輸出后，報(bào)告解讀，其中54017是指進(jìn)程號(hào)，如果程序使用了多進(jìn)程的方式來(lái)執(zhí)行，那么就會(huì)顯示多個(gè)進(jìn)程的內(nèi)容。

第二段是對(duì)堆內(nèi)存分配的總結(jié)信息，其中提到程序一共申請(qǐng)了1次內(nèi)存，其中0次釋放了，4 bytes被分配(1 allocs, 0 frees, 4 bytes allocated)。

在head summary中，有該程序使用的總heap內(nèi)存量，分配內(nèi)存次數(shù)和釋放內(nèi)存次數(shù)，如果分配內(nèi)存次數(shù)和釋放內(nèi)存次數(shù)不一致則說(shuō)明有內(nèi)存泄漏。

第三段的內(nèi)容描述了內(nèi)存泄露的具體信息，其中有一塊內(nèi)存占用4字節(jié)（4 bytes in 1 blocks），在調(diào)用malloc分配，調(diào)用棧中可以看到是func函數(shù)最后調(diào)用了malloc，所以這一個(gè)信息是比較準(zhǔn)確的定位了我們泄露的內(nèi)存是在哪里申請(qǐng)的。

最后這一段是總結(jié)，4字節(jié)為一塊的內(nèi)存泄露。

讀寫越界

problem1: 指針pt申請(qǐng)了空間，但是沒(méi)有釋放; problem2: pt申請(qǐng)了5個(gè)int的空間，p經(jīng)過(guò)5次循環(huán)已達(dá)到p[5]的位置,?*p = 5時(shí)，訪問(wèn)越界（寫越界）。(下面valgrind報(bào)告中 Invalid write of size 4)

problem1: 讀越界 (下面valgrind報(bào)告中 Invalid read of size 4 )

重復(fù)釋放

報(bào)告如下，Invalid free() / delete / delete[] / realloc()

申請(qǐng)釋放接口不匹配

申請(qǐng)釋放接口不匹配的報(bào)告如下，用malloc申請(qǐng)空間的指針用free釋放；用new申請(qǐng)的空間用delete釋放(Mismatched free() / delete / delete [])：

內(nèi)存覆蓋

問(wèn)題出在memcpy上， 將str指針位置開始copy 5個(gè)char到str+1所指空間，會(huì)造成內(nèi)存覆蓋。strncpy也是同理。報(bào)告如下，Source and destination overlap：

三、總結(jié)

內(nèi)存檢測(cè)方式無(wú)非分為兩種：

1、維護(hù)一個(gè)內(nèi)存操作鏈表，當(dāng)有內(nèi)存申請(qǐng)操作時(shí)，將其加入此鏈表中，當(dāng)有釋放操作時(shí)，從申請(qǐng)操作從鏈表中移除。如果到程序結(jié)束后此鏈表中還有內(nèi)容，說(shuō)明有內(nèi)存泄露了；如果要釋放的內(nèi)存操作沒(méi)有在鏈表中找到對(duì)應(yīng)操作，則說(shuō)明是釋放了多次。使用此方法的有內(nèi)置的調(diào)試工具，Visual Leak Detecter，mtrace, memwatch, debug_new。2、模擬進(jìn)程的地址空間。仿照操作系統(tǒng)對(duì)進(jìn)程內(nèi)存操作的處理，在用戶態(tài)下維護(hù)一個(gè)地址空間映射，此方法要求對(duì)進(jìn)程地址空間的處理有較深的理解。因?yàn)閃indows的進(jìn)程地址空間分布不是開源的，所以模擬起來(lái)很困難，因此只支持Linux。采用此方法的是 valgrind。

原文作者：一起學(xué)嵌入式