溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
小編給大家分享一下怎么通過wrap malloc定位C/C++的內存泄漏問題，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
用C/C++開發的程序執行效率很高，但卻經常受到內存泄漏的困擾。本文提供一種通過wrap malloc查找memory leak的思路，依靠這個方法，筆者緊急解決了內存泄漏問題，避免項目流血上大促，該方法在日后工作中大放光彩，發現了項目中大量沉疴已久的內存泄漏問題。
動態申請的內存丟失引用，造成沒有辦法回收它（我知道杠jing要說進程退出前系統會統一回收），這便是內存泄漏。
Java等編程語言會自動管理內存回收，而C/C++需要顯式的釋放，有很多手段可以避免內存泄漏，比如RAII，比如智能指針（大多基于引用計數計數），比如內存池。
理論上，只要我們足夠小心，在每次申請的時候，都牢記釋放，那這個世界就清凈了，但現實往往沒有那么美好，比如拋異常了，釋放內存的語句執行不到，又或者某菜鳥程序員不小心埋了一個雷，所以，我們必須直面真實的世界，那就是我們會遭遇內存泄漏。
我們可以review代碼，但從海量代碼里找到隱藏的問題，這如同大海撈針，往往兩手空空。
所以，我們需要借助工具，比如valgrind，但這些找內存泄漏的工具，往往對你使用動態內存的方式有某種期待，或者說約束，比如常駐內存的對象會被誤報出來，然后真正有用的信息會掩蓋在誤報的汪洋大海里。很多時候，甚至valgrind根本解決不了日常項目中的問題。
所以很多著名的開源項目，為了能用valgrind跑，都費大力氣，大幅修改源代碼，從而使得項目符合valgrind的要求，滿足這些要求，用valgrind跑完沒有任何報警的項目叫valgrind干凈。
既然這些玩意兒都中看不中用，所以，求人不如求己，還是得自力更生。
動態內存分配器是介于kernel跟應用程序之間的一個函數庫，glibc提供的動態內存分配器叫ptmalloc，它也是應用最廣泛的動態內存分配器實現。
從kernel角度看，動態內存分配器屬于應用程序層；而從應用程序的角度看，動態內存分配器屬于系統層。
應用程序可以通過mmap系統直接向kernel申請動態內存，也可以通過動態內存分配器的malloc接口分配內存，而動態內存分配器會通過sbrk、mmap向kernel分配內存，所以應用程序通過free釋放的內存，并不一定會真正返還給系統，它也有可能被動態內存分配器緩存起來。
google有自己的動態內存分配器tcmalloc，另外jemalloc也是著名的動態內存分配器，他們有不同的性能表現，也有不同的緩存和分配策略。你可以用它們替換linux系統glibc自帶的ptmalloc。
new是c++的用法，比如Foo *f = new Foo，其實它分為3步。
（1）通過operator new()分配sizeof(Foo)的內存，最終通過malloc分配。
（2）在新分配的內存上構建Foo對象。
（3）返回新構建的對象地址。
new=分配內存+構造+返回，而delete則是等于析構+free。
所以搞定malloc、free就是從根本上搞定動態內存分配。
每次通過malloc返回的一塊內存叫一個chunk，動態內存分配器是這樣定義的，后面我們都這樣稱呼。
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被分配，從而去檢查是不是正確釋放了。
我們可以維護一個全局 unsigned int malloc_map[1024 * 1024]數組，該數組的下標就是chunk的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的分配量。
不對，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工具可以做到，你可以追查到調用鏈，進而定位到內存泄漏的問題。
至此，你已經get到了整個核心思想。
當然，實際項目中，我們做的更多，我們不僅僅記錄了toplist size，還記錄了各size chunk的增量toplist，會記錄大塊的malloc/free，會wrap更多的API。
以上是“怎么通過wrap malloc定位C/C++的內存泄漏問題”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
