首頁>技術>

用C/C++開發的程式執行效率很高,但卻經常受到記憶體洩漏的困擾。本文提供一種通過wrap malloc查詢memory leak的思路。

什麼是記憶體洩漏?

動態申請的記憶體丟失引用,造成沒有辦法回收它(我知道槓jing要說程序退出前系統會統一回收),這便是記憶體洩漏。

Java等程式語言會自動管理記憶體回收,而C/C++需要顯式的釋放,有很多手段可以避免記憶體洩漏,比如RAII,比如智慧指標(大多基於引用計數計數),比如記憶體池。

理論上,只要我們足夠小心,在每次申請的時候,都牢記釋放,那這個世界就清淨了,但現實往往沒有那麼美好,比如拋異常了,釋放記憶體的語句執行不到,又或者某菜鳥程式設計師不小心埋了一個雷,所以,我們必須直面真實的世界,那就是我們會遭遇記憶體洩漏。

怎麼查記憶體洩漏?

我們可以review程式碼,但從海量程式碼裡找到隱藏的問題,這如同大海撈針,往往兩手空空。

所以,我們需要藉助工具,比如valgrind,但這些找記憶體洩漏的工具,往往對你使用動態記憶體的方式有某種期待,或者說約束,比如常駐記憶體的物件會被誤報出來,然後真正有用的資訊會掩蓋在誤報的汪洋大海里。很多時候,甚至valgrind根本解決不了日常專案中的問題。

所以很多著名的開源專案,為了能用valgrind跑,都費大力氣,大幅修改原始碼,從而使得專案符合valgrind的要求,滿足這些要求,用vargrind跑完沒有任何報警的專案叫valgrind乾淨專案。

既然這些玩意兒都中看不中用,所以,求人不如求己,還是得自己自力更生。

什麼是動態記憶體分配器?

動態記憶體分配器是介於kernel跟應用程式之間的一個函式庫,glibc提供的動態記憶體分配器叫ptmalloc,它也是應用最廣泛的動態記憶體分配器實現。

從kernel角度看,動態記憶體分配器屬於應用程式層;而從應用程式的角度看,動態記憶體分配器屬於系統層。

應用程式可以通過mmap系統直接向kernel申請動態記憶體,也可以通過動態記憶體分配器的malloc介面分配記憶體,而動態記憶體分配器會通過sbrk、mmap向kernel分配記憶體,所以應用程式通過free釋放的記憶體,並不一定會真正返還給系統,它也有可能被動態記憶體分配器快取起來。

google有自己的動態記憶體分配器tcmalloc,另外jemalloc也是著名的動態記憶體分配器,他們有不同的效能表現,也有不同的快取和分配策略。你可以用它們替換linux系統glibc自帶的ptmalloc。

new/delete跟malloc/free的關係

new是c++的用法,比如Foo *f = new Foo,其實它分為3步。

通過operator new()分配sizeof(Foo)的記憶體,最終通過malloc分配。在新分配的記憶體上構建Foo物件。返回新構建的物件地址。

new=分配記憶體+構造+返回,而delete則是等於析構+free。

所以搞定malloc、free就是從根本是搞定動態記憶體分配。

chunk

每次通過malloc返回的一塊記憶體叫一個chunk,動態記憶體分配器是這樣定義的,後面我們都這樣稱呼。

wrap malloc

gcc支援wrap,即通過傳遞-Wl,--wrap,malloc的方式,可以改變呼叫malloc的行為,把對malloc的呼叫連結到自定義的__wrap_malloc(size_t)函式,而我們可以在__wrap_malloc(size_t)函式的實現中通過__real_malloc(size_t)真正分配記憶體,而後我們可以做搞點小動作。

同樣,我們可以wrap free。malloc跟free是配對的,當然也有其他相關API,比如calloc、realloc、valloc,但這根本上還是malloc+free,比如realloc就是malloc + free。

怎麼去定位記憶體洩漏呢?

我們會malloc各種不同size的chunk,也就是每種不同size的chunk會有不同數量,如果我們能夠跟蹤每種size的chunk數量,那就可以知道哪種size的chunk在洩漏。很簡單,如果該size的chunk數量一直在增長,那它很可能洩漏。

光知道某種size的chunk洩漏了還不夠,我們得知道是哪個呼叫路徑上導致該size的chunk被分配,從而去檢查是不是正確釋放了。

怎麼跟蹤到每種size的chunk數量?

我們可以維護一個全域性 unsigned int malloc_map[1024 * 1024]陣列,該陣列的下標就是chun的size,malloc_map[size]的值就對應到該size的chunk分配量。

這等於維護了一個chunk size到chunk count的對映表,它足夠快,而且它可以覆蓋到0 ~ 1M大小的chunk的範圍,它已經足夠大了,試想一次分配一兆的塊已經很恐怖了,可以覆蓋到大部分場景。

那大於1M的塊怎麼辦呢?我們可以通過log記錄下來。

在__wrap_malloc裡,++malloc_map[size]

在__wrap_free裡,--malloc_map[size]

很簡單,我們通過malloc_map記錄了各size的chunk的分配量。

如何知道釋放的chunk的size?

不對,free(void *p)只有一個引數,我如何知道釋放的chunk的size呢?怎麼辦?

我們通過在__wrap_malloc(size_t)的時候,分配8+size的chunk,也就是多分配8位元組,開始的8位元組儲存該chunk的size,然後返回的是(char*)chunk + 8,也就是偏移8個位元組返回給呼叫malloc的應用程式。

這樣在free的時候,傳入引數void* p,我們把p往前移動8個位元組,解引用就能得到該chunk的大小,而該大小值就是前一步,在__wrap_malloc的時候設定的size。

好了,我們真正做到記錄各size的chunk數量了,它就存在於malloc_map[1M]的陣列中,假設64個位元組的chunk一直在被分配,數量一直在增長,我們覺得該size的chunk很有可能洩漏,那怎麼定位到是哪裡呼叫過來的呢?

如何記錄呼叫鏈?

我們可以維護一個toplist陣列,該陣列假設有10個元素,它儲存的是chunk數最大的10種size,這個很容易做到,通過對malloc_map取top 10就行。

然後我們在__wrap_malloc(size_t)裡,測試該size是不是toplist之一,如果是的話,那我們通過glibc的backtrace把呼叫堆疊dump到log檔案裡去。

注意:這裡不能再分配記憶體,所以你只能使用backtrace,而不能使用backtrace_symbols,這樣你只能得到呼叫堆疊的符號地址,而不是符號名。

如何把符號地址轉換成符號名,也就是對於到程式碼行呢?

addr2line

addr2line工具可以做到,你可以追查到呼叫鏈,進而定位到記憶體洩漏的問題。

至此,你已經get到了整個核心思想。

當然,實際專案中,我們做的更多,我們不僅僅記錄了toplist size,還記錄了各size chunk的增量toplist,會記錄大塊的malloc/free,會malloc更多的API。

總結一下:通過wrap malloc/free + backtrace + addr2line,你就可以定位到記憶體洩漏了。

美好的時間過得太快,有是時候說byebye。

  • BSA-TRITC(10mg/ml) TRITC-BSA 牛血清白蛋白改性標記羅丹明
  • 伺服器架構:十張圖帶你了解大型網站架構