做嵌入式或者系統(tǒng)級(jí)開發(fā)的朋友大概率都有過被內(nèi)存問題折磨到抓狂的經(jīng)歷。程序跑著跑著內(nèi)存持續(xù)上漲、隨機(jī)出現(xiàn)段錯(cuò)誤、某個(gè)模塊退出時(shí)崩潰……這類問題查起來極其磨人。Valgrind、AddressSanitizer 都是好工具但總有那么一些場景它們不太適用交叉編譯環(huán)境跑不了、性能開銷大到無法接受、或者你用的分配器根本不是 glibc 默認(rèn)的那個(gè)。于是我自己動(dòng)手做了一個(gè)自定義內(nèi)存檢測(cè)工具在項(xiàng)目里實(shí)測(cè)下來幫我定位了不少隱藏很深的泄漏和越界問題今天就把這套思路完整分享出來。這個(gè)工具解決的核心問題是在不放慢程序太多、不依賴特殊運(yùn)行時(shí)的情況下給 C/C 項(xiàng)目加一層“內(nèi)存分配監(jiān)控網(wǎng)”。它能查泄漏、查越界寫、查重復(fù)釋放、查未初始化讀取而且最關(guān)鍵的是——它是可定制的。你可以按自己的項(xiàng)目場景調(diào)整檢測(cè)粒度、開關(guān)特定檢查項(xiàng)、對(duì)接自定義內(nèi)存池。適合被內(nèi)存問題困擾的 C/C 開發(fā)者、嵌入式工程師、游戲引擎/client 端開發(fā)者以及任何想搞懂“內(nèi)存檢測(cè)工具底層到底怎么工作”的人。1. 為什么我要自己寫一個(gè)內(nèi)存檢測(cè)工具1.1 現(xiàn)成工具的短板什么時(shí)候它們不夠用先把話說清楚Valgrind 和 AddressSanitizer 都是極其優(yōu)秀的工具我至今還在用它們。但它們有幾個(gè)在實(shí)際項(xiàng)目里很難繞開的限制交叉編譯平臺(tái)上跑不了。Valgrind 需要針對(duì)目標(biāo)架構(gòu)編譯它的運(yùn)行時(shí)很多嵌入式平臺(tái)根本編譯不過去。ASan 雖然支持交叉編譯但要在目標(biāo)板上跑起來對(duì)工具鏈版本要求很苛刻。性能開銷太高。Valgrind 平均會(huì)拖慢程序 10 到 50 倍在大型 GUI 程序或圖像處理項(xiàng)目里這種速度基本上沒法做實(shí)時(shí)操作。ASan 大概拖慢 2 倍左右但內(nèi)存占用會(huì)翻好幾倍。對(duì)自定義內(nèi)存分配器“無感”。如果你的項(xiàng)目用了內(nèi)存池、對(duì)象池、tlsf 這類自定義分配器Valgrind 和 ASan 默認(rèn)是看不到池內(nèi)部的分配和釋放行為的。你唯一能看到的是池一次性向系統(tǒng)申請(qǐng)了大塊內(nèi)存池內(nèi)部誰泄漏了、誰越界了它們管不著。團(tuán)隊(duì)環(huán)境不統(tǒng)一。開發(fā)機(jī)、CI 機(jī)器、客戶現(xiàn)場環(huán)境各不相同讓所有人都部署一套 Valgrind 不太現(xiàn)實(shí)。相比之下一個(gè)集成在項(xiàng)目內(nèi)部的、用宏和鏈接器包裝實(shí)現(xiàn)的自定義內(nèi)存檢測(cè)工具可以在任何平臺(tái)上編譯開銷可控還能專門針對(duì)自己的內(nèi)存池做定制檢測(cè)。它的定位不是替代 Valgrind而是填補(bǔ) Valgrind 在特定場景下覆蓋不到的空檔。1.2 自定義內(nèi)存檢測(cè)工具的定位輕量、可控、貼合場景我做的這個(gè)東西本質(zhì)上是一個(gè)“包裹層”。它包在系統(tǒng)分配器或你的自定義分配器外層每次分配和釋放都經(jīng)過它記賬然后在關(guān)鍵節(jié)點(diǎn)上做校驗(yàn)。設(shè)計(jì)目標(biāo)有三個(gè)輕量。不用在每次分配時(shí)做太重的操作記錄文件行號(hào)和簡要調(diào)用棧就夠了不追求像 Valgrind 那樣精確到每條指令?？煽亍Ｍㄟ^編譯開關(guān)控制檢測(cè)項(xiàng)。比如發(fā)布版本可以直接退化成“僅統(tǒng)計(jì)內(nèi)存占用”不用做任何越界檢查。貼合場景。項(xiàng)目里用到的對(duì)象池、固定塊分配器、線程局部緩存都能掛接到這個(gè)框架下做統(tǒng)一記賬。這些目標(biāo)決定了后面所有的設(shè)計(jì)決策。2. 設(shè)計(jì)思路先想清楚怎么“接”進(jìn)項(xiàng)目2.1 核心原理攔截分配與釋放做簿記內(nèi)存檢測(cè)的根本原理說白了就一句話把每一次分配和釋放都記下來。你只要能在分配時(shí)知道“誰在哪個(gè)文件的哪一行分配了多少字節(jié)”在釋放時(shí)知道“這塊內(nèi)存是否真的合法”就能推導(dǎo)出很多結(jié)論。實(shí)現(xiàn)攔截有三種主流方案宏替換。在頭文件里#define malloc(size) my_malloc(size, __FILE__, __LINE__)。這是最簡單直接的方案能拿到文件和行號(hào)但有一個(gè)致命弱點(diǎn)只能攔截“包含這個(gè)頭文件”的代碼。第三方庫、同事的 .c 文件如果沒包含就直接繞過檢測(cè)了。鏈接器符號(hào)包裝。GCC/Clang 提供--wrapmalloc選項(xiàng)鏈接時(shí)把所有對(duì)malloc的調(diào)用都重定向到__wrap_malloc你在__wrap_malloc里記賬然后調(diào)__real_malloc干正事。這個(gè)方案能攔截整個(gè)程序里所有對(duì) malloc 的調(diào)用不依賴頭文件包含非常干凈。dlsym(RTLD_NEXT) 運(yùn)行時(shí)劫持。運(yùn)行時(shí)通過動(dòng)態(tài)鏈接器找到真正的 malloc 地址然后自己定義同名函數(shù)。方案很靈活但實(shí)現(xiàn)復(fù)雜還容易在非 glibc 平臺(tái)上踩坑。我最終的做法是宏替換 鏈接器包裝雙管齊下。項(xiàng)目自己的代碼用宏替換拿到文件行號(hào)第三方庫的分配行為用--wrap兜底。兩個(gè)方案互不沖突因?yàn)楹晏鎿Q后調(diào)的是my_malloc而鏈接器包裝只攔截符號(hào)名malloc。2.2 關(guān)鍵數(shù)據(jù)結(jié)構(gòu)設(shè)計(jì)在分配塊上“貼條”攔截到分配之后必須把簿記信息存下來。我的方案是在每個(gè)分配塊的前面加一個(gè)頭部結(jié)構(gòu)這就是所謂的“貼條”typedef struct mem_header { uint32_t magic; // 魔數(shù)用于識(shí)別合法頭部 size_t size; // 用戶請(qǐng)求的字節(jié)數(shù) const char *file; // 分配點(diǎn)文件名 int line; // 分配點(diǎn)行號(hào) void *return_addr; // 調(diào)用點(diǎn)返回地址用于自定義調(diào)用棧 struct mem_header *next; // 全局分配鏈表的 next struct mem_header *prev; // 全局分配鏈表的 prev uint32_t head_guard; // 數(shù)據(jù)前的哨兵字節(jié) } mem_header; #define HEADER_GUARD_PATTERN 0xFDA4A5D5用戶拿到的指針是(char*)header sizeof(mem_header)。釋放檢查時(shí)用用戶指針減去頭部大小就能找到 header。head_guard和塊尾的tail_guard合起來用于越界檢測(cè)。這個(gè)鏈表的每個(gè)節(jié)點(diǎn)都記錄了分配信息而且是一個(gè)雙向鏈表方便在釋放時(shí) O(1) 摘除節(jié)點(diǎn)。實(shí)際項(xiàng)目里分配次數(shù)可能上百萬次如果從頭遍歷找節(jié)點(diǎn)一次釋放就是 O(n)整體會(huì)變成 O(n^2)程序基本跑不動(dòng)。所以雙向鏈表是必須的。2.3 檢測(cè)能力設(shè)計(jì)泄漏、越界、重復(fù)釋放、統(tǒng)計(jì)一份工具要實(shí)用必須明確自己能輸出什么結(jié)論。我把檢測(cè)能力拆成四塊泄漏檢測(cè)退出時(shí)遍歷全局分配鏈表把未被釋放的節(jié)點(diǎn)按文件行號(hào)聚合并打印直接告訴你哪個(gè)文件哪一行泄漏了 N 次、總字節(jié)數(shù)多少。越界檢測(cè)分配時(shí)在用戶數(shù)據(jù)前后各放一段哨兵字節(jié)0xFD 模式釋放時(shí)逐一對(duì)比任何一個(gè)字節(jié)被改動(dòng)就說明發(fā)生了越界寫。塊尾哨兵尤其容易踩到因?yàn)閿?shù)組越界寫是最常見的內(nèi)存錯(cuò)誤。重復(fù)釋放檢測(cè)釋放時(shí)檢查 header 的 magic 是否還是有效值如果是 0 或別的說明這塊內(nèi)存已經(jīng)被釋放過。更嚴(yán)謹(jǐn)一點(diǎn)釋放后把 magic 改成0xDEADBEEF同時(shí)把用戶區(qū)填成 0xDD這樣再次釋放和“釋放后使用”都能被捕捉。內(nèi)存統(tǒng)計(jì)維護(hù)全局的已分配字節(jié)數(shù)、峰值、分配次數(shù)、釋放次數(shù)。這些數(shù)據(jù)對(duì)定位內(nèi)存持續(xù)增長問題非常關(guān)鍵——如果你發(fā)現(xiàn)分配次數(shù)和釋放次數(shù)之差在增長即使沒看到明顯的泄漏點(diǎn)也能確認(rèn)方向。3. 核心實(shí)現(xiàn)一步步把工具擼出來3.1 入口層鏈路包裝與宏定義先看頭文件memtrack.h的設(shè)計(jì)。這是用戶唯一需要 include 的頭文件#ifndef MEMTRACK_H #define MEMTRACK_H #include stddef.h #include stdint.h #ifdef MEMTRACK_ENABLED #define malloc(sz) mt_malloc(sz, __FILE__, __LINE__) #define calloc(n, sz) mt_calloc(n, sz, __FILE__, __LINE__) #define realloc(ptr, sz) mt_realloc(ptr, sz, __FILE__, __LINE__) #define free(ptr) mt_free(ptr) void *mt_malloc(size_t size, const char *file, int line); void *mt_calloc(size_t n, size_t size, const char *file, int line); void *mt_realloc(void *ptr, size_t size, const char *file, int line); void mt_free(void *ptr); #else // 禁用時(shí)直接調(diào)系統(tǒng)分配器零開銷 #define mt_malloc(sz, file, line) malloc(sz) #define mt_calloc(n, sz, file, line) calloc(n, sz) #define mt_realloc(ptr, sz, file, line) realloc(ptr, sz) #define mt_free(ptr) free(ptr) #endif #endif這是最經(jīng)典的外層接口。啟用宏替換后項(xiàng)目代碼里每個(gè)malloc(1024)都會(huì)被展開為mt_malloc(1024, main.cpp, 12)文件行號(hào)自然就帶上了。這里要注意宏替換只針對(duì)“看到這個(gè)頭文件”的翻譯單元所以必須在項(xiàng)目統(tǒng)一包含的頭文件里引入比如common.h。3.2 簿記實(shí)現(xiàn)的完整性接下來是memtrack.c里的核心實(shí)現(xiàn)。先看分配函數(shù)是怎么把 header 和用戶數(shù)據(jù)拼在一起的void *mt_malloc(size_t size, const char *file, int line) { // 在用戶請(qǐng)求大小之外多分配 header 和尾部哨兵的空間 size_t total sizeof(mem_header) size sizeof(uint32_t); mem_header *hdr (mem_header *)real_malloc(total); if (!hdr) return NULL; hdr-magic HEADER_MAGIC; hdr-size size; hdr-file file; hdr-line line; hdr-return_addr __builtin_return_address(0); hdr-head_guard HEADER_GUARD_PATTERN; hdr-next alloc_list; hdr-prev NULL; if (alloc_list) alloc_list-prev hdr; alloc_list hdr; // 頭哨兵之后的區(qū)域是用戶數(shù)據(jù) char *user_ptr (char *)(hdr 1); // 尾部哨兵 uint32_t *tail_guard (uint32_t *)(user_ptr size); *tail_guard HEADER_GUARD_PATTERN; // 新分配的內(nèi)存全部填 0xCD方便識(shí)別未初始化讀寫 memset(user_ptr, 0xCD, size); // 記錄統(tǒng)計(jì) total_allocated_bytes size; total_alloc_count; if (total_allocated_bytes peak_allocated_bytes) peak_allocated_bytes total_allocated_bytes; return user_ptr; }這里real_malloc是真正的系統(tǒng)分配器。在宏替換之外我會(huì)把real_malloc指向__real_malloc——如果你用-Wl,--wrapmalloc鏈接鏈接器會(huì)幫你自動(dòng)提供__real_malloc這個(gè)符號(hào)如果沒啟用鏈接器包裝就把它定義為malloc的別名。兩種模式通過宏切換。有人可能會(huì)問為什么要多分配一個(gè) header 空間而不是在維護(hù)一個(gè)全局哈希表記錄分配信息哈希表方案也能用但問題是釋放時(shí)要通過指針查到對(duì)應(yīng)的記錄哈希表 O(1) 查找沒問題但一旦指針被越界寫破壞成一個(gè)野值哈希表就直接查無記錄你無法確定到底哪里出了問題。而 header 方案下指針被破壞時(shí)你拿去減掉 header 大小拿到的可能是隨機(jī)值但至少magic校驗(yàn)?zāi)芰⒖谈嬖V你“這塊內(nèi)存的頭被踩了”這對(duì)于定位越界寫非常有幫助。3.3 釋放與校驗(yàn)把賬對(duì)平釋放時(shí)要做的事情明顯更多這是整個(gè)工具最核心的一段邏輯void mt_free(void *ptr) { if (!ptr) return; mem_header *hdr (mem_header *)((char *)ptr - sizeof(mem_header)); // 1. 檢查 head_guard 是否被蹂躪 if (hdr-head_guard ! HEADER_GUARD_PATTERN) { report_error(頭哨兵被破壞指針 %p 可能存在越界寫, ptr); return; // 不繼續(xù)釋放防止二次破壞 } // 2. 檢查 magic 判斷是否重復(fù)釋放 if (hdr-magic ! HEADER_MAGIC) { report_error(重復(fù)釋放或指針非法magic0x%08Xptr%p, hdr-magic, ptr); return; } // 3. 檢查 tail_guard uint32_t *tail_guard (uint32_t *)((char *)ptr hdr-size); if (*tail_guard ! HEADER_GUARD_PATTERN) { report_error(尾部哨兵被破壞: %s:%d 分配的大小為 %zu 字節(jié)寫入越界, hdr-file, hdr-line, hdr-size); } // 4. 將 magic 置為已釋放標(biāo)記并把用戶區(qū)填 0xDD hdr-magic FREED_MAGIC; memset(ptr, 0xDD, hdr-size); // 5. 從全局鏈表中摘除 if (hdr-prev) hdr-prev-next hdr-next; else alloc_list hdr-next; if (hdr-next) hdr-next-prev hdr-prev; // 6. 更新統(tǒng)計(jì) total_allocated_bytes - hdr-size; total_free_count; // 7. 真正釋放給系統(tǒng) real_free(hdr); }這段代碼里有幾個(gè)細(xì)節(jié)值得展開講。釋放后填 0xDD 而不是立即還給系統(tǒng)這是個(gè)刻意的設(shè)計(jì)。它能讓你在調(diào)試時(shí)一眼看出“這塊內(nèi)存已經(jīng)被釋放了”——0xDD 在調(diào)試器里顯示為“燙燙燙”取決于編碼和工具非常醒目。更重要的是如果釋放后代碼繼續(xù)用這個(gè)指針讀到的全是 0xDD很容易和正常數(shù)據(jù)區(qū)分。小概率的 head_guard 失效問題head_guard只能檢測(cè)“向后越界寫”。如果前一塊的內(nèi)存越界寫把 header 區(qū)域覆蓋了magic會(huì)變但你沒法知道是誰干的。這時(shí)候就要配合“分配塊日志”來查在報(bào)告里打印出鄰近分配的 file:line通常能找到線索。3.4 泄漏報(bào)告退出時(shí)清點(diǎn)現(xiàn)場泄漏報(bào)告在程序退出時(shí)觸發(fā)。我用atexit注冊(cè)一個(gè)回調(diào)函數(shù)在exit()時(shí)遍歷全局鏈表static void leak_report(void) { mem_header *it alloc_list; int leak_count 0; size_t leak_bytes 0; while (it) { leak_count; leak_bytes it-size; fprintf(stderr, [LEAK] %s:%d 泄漏 %zu 字節(jié) (ptr%p), 調(diào)用返回地址 %p\n, it-file ? it-file : ?, it-line, it-size, (char *)(it 1), it-return_addr); it it-next; } fprintf(stderr, [MEMTRACK] 泄漏塊總數(shù): %d, 總字節(jié)數(shù): %zu\n, leak_count, leak_bytes); }這里有個(gè)提升報(bào)告精度的技巧按 file:line 聚合統(tǒng)計(jì)。如果泄漏發(fā)生在循環(huán)里一次性可能打上千條記錄刷屏刷到看不到重點(diǎn)。實(shí)際項(xiàng)目中我用了一個(gè)哈希表把相同的 file:line 聚合起來最后只輸出按泄漏字節(jié)數(shù)倒序排序的前 30 行。這個(gè)改造對(duì)報(bào)告的可讀性提升非常大。3.5 對(duì)齊問題的處理不然崩到懷疑人生寫這個(gè)工具時(shí)最容易踩的一個(gè)大坑就是對(duì)齊。C/C 標(biāo)準(zhǔn)里malloc返回的指針必須滿足最嚴(yán)格的對(duì)齊要求通常是 16 字節(jié)對(duì)齊。如果你簡單地在用戶指針前面放一個(gè)mem_header然后返回(char*)hdr sizeof(mem_header)這個(gè)地址很可能不再是對(duì)齊的。一旦用戶在這個(gè)地址上存放double、__m128i這類需要嚴(yán)格對(duì)齊的類型程序會(huì)直接崩潰。解決辦法是在設(shè)計(jì) header 大小的時(shí)候就讓它成為 16 的整數(shù)倍或者在分配時(shí)額外多分配一個(gè)“對(duì)齊偏移量”再把用戶地址手動(dòng)對(duì)齊到 16 字節(jié)邊界。簡化版的實(shí)現(xiàn)是#define ALIGNMENT 16 size_t total sizeof(mem_header) ALIGNMENT size sizeof(uint32_t); char *raw (char *)real_malloc(total); uintptr_t user_addr (uintptr_t)(raw sizeof(mem_header) ALIGNMENT) ~(ALIGNMENT - 1); mem_header *hdr (mem_header *)(user_addr - sizeof(mem_header));但這種做法需要額外字段記錄原始分配地址否則釋放時(shí)對(duì)齊不回來。最省心的方案還是“header 大小強(qiáng)制對(duì)齊”用__attribute__((aligned(16)))修飾結(jié)構(gòu)體保證sizeof(mem_header)是 16 的倍數(shù)然后直接返回hdr 1就是對(duì)齊的。這個(gè)做法我用了很久沒有再出過對(duì)齊崩的問題。4. 實(shí)操中的坑與排查技巧實(shí)錄4.1 性能開銷如何做到可接受的回落最初版本我每次分配都調(diào)用backtrace()采集完整調(diào)用棧結(jié)果程序直接慢了 30 倍完全沒法用。后來我只記錄__builtin_return_address(0)——也就是調(diào)用點(diǎn)上一層的返回地址配合地址轉(zhuǎn)符號(hào)表addr2line或者dladdr在報(bào)告階段再解析性能開銷降到了可接受范圍。實(shí)測(cè)下來啟用完整檢測(cè)后項(xiàng)目運(yùn)行速度大約是原來的 70% 到 80%。這在開發(fā)調(diào)試階段完全可以接受。如果嫌慢還有幾個(gè)開關(guān)可以關(guān)尾部哨兵檢查、釋放后填充、調(diào)用地址記錄。關(guān)掉后基本能恢復(fù)到接近原始速度。性能開銷主要來自三個(gè)地方全局鏈表的鎖競爭、哨兵字節(jié)的 memset 和對(duì)比、統(tǒng)計(jì)變量的原子操作。多線程場景下鎖競爭是最大瓶頸我在 4.3 節(jié)專門講。4.2 重入問題日志打印里藏著的死循環(huán)這是所有內(nèi)存檢測(cè)工具都會(huì)踩的經(jīng)典坑在 malloc/free 里調(diào)用 printf 打印日志而 printf 內(nèi)部又調(diào)用 malloc于是進(jìn)入無限遞歸。遇到這個(gè)問題的第一反應(yīng)是加一個(gè)“重入標(biāo)志”static __thread int in_hook 0; void mt_free(void *ptr) { if (in_hook) { // 重入直接放行不記賬 real_free(ptr); return; } in_hook 1; // ...正常檢測(cè)邏輯輸出日志 in_hook 0; }__thread保證了多線程下每個(gè)線程有自己的標(biāo)志不會(huì)互相干擾。這個(gè)小小的保護(hù)讓工具的穩(wěn)定性上了一大截。4.3 多線程競爭全局鏈表與鎖策略項(xiàng)目里開了 8 個(gè)線程同時(shí)分配內(nèi)存檢測(cè)工具的全局鏈表變成了一片戰(zhàn)場。用一把互斥鎖保護(hù)鏈表簡單但會(huì)導(dǎo)致線程間嚴(yán)重互斥性能下降明顯。我后來用了一個(gè) 64 槽位的哈希表把分配頭按地址 hash 到不同的桶每個(gè)桶一把獨(dú)立的小鎖。這樣不同線程分配的塊大概率落在不同桶里鎖爭用大幅下降。槽位數(shù)量怎么定的我參考了“一核一線程一槽位”的粗粒度思路64 個(gè)桶對(duì) 8 到 16 線程的項(xiàng)目來說足夠了。如果線程更多可以按線程數(shù) * 4調(diào)整桶數(shù)量。更精細(xì)的方案是用線程局部存儲(chǔ)加無鎖鏈表每個(gè)線程只操作自己的分配記錄最后匯總。這個(gè)實(shí)現(xiàn)復(fù)雜度高不少個(gè)人小工具里做不做取決于項(xiàng)目規(guī)模。對(duì)我來說哈希桶鎖已經(jīng)解決了實(shí)際問題。4.4 誤報(bào)排查哪些“泄漏”不是真泄漏用這個(gè)工具跑了幾天后我開始收到一些“看起來像泄漏”的報(bào)告。排查后發(fā)現(xiàn)有幾類經(jīng)典情況長期存活的單例對(duì)象。比如全局配置管理器在程序啟動(dòng)時(shí) new 一次直到退出才釋放。這類對(duì)象嚴(yán)格來說沒被釋放但不會(huì)造成內(nèi)存增長不算真泄漏。處理辦法是維護(hù)一個(gè)白名單文件把已知的合法長生命周期分配排除掉。靜態(tài)初始化/反初始化順序問題。某些平臺(tái)在atexit回調(diào)執(zhí)行時(shí)某些全局對(duì)象已經(jīng)被銷毀此時(shí)訪問它的成員會(huì)導(dǎo)致崩潰。我的leak_report里有一個(gè)小技巧報(bào)告階段通過is_address_freed()檢查文件名字符串指針是否指向已釋放內(nèi)存如果已經(jīng)釋放就打印freed而不是直接訪問。第三方庫內(nèi)部緩存。有些庫會(huì)在退出時(shí)保留線程局部緩存以加速下一次調(diào)用。這些緩存必須被特殊標(biāo)記否則會(huì)出現(xiàn)“看起來”泄漏但實(shí)際無害的報(bào)表。我在接口里加了一個(gè)mt_mark_global(void *ptr)函數(shù)允許外部把一塊分配標(biāo)記為“全局存活”從泄漏報(bào)告里排除。遇到這些“假陽性”關(guān)鍵是先搞清楚泄漏報(bào)告里的分配點(diǎn)是哪里、關(guān)聯(lián)的對(duì)象生命周期是怎樣的。不要急著改代碼先加日志確認(rèn)。5. 擴(kuò)展實(shí)戰(zhàn)把檢測(cè)工具接到自定義內(nèi)存池上5.1 固定塊分配器為什么標(biāo)準(zhǔn)工具管不到前面提過Valgrind 和 ASan 對(duì)自定義內(nèi)存池基本無能為力。但實(shí)際項(xiàng)目中我最需要檢測(cè)的恰恰是自己寫的固定塊分配器。這種分配器一般持有一大塊連續(xù)內(nèi)存切成固定大小的塊用空閑鏈表串起來。它向用戶返回的指針來自池內(nèi)不是系統(tǒng)分配器返回的所以系統(tǒng)級(jí)工具完全感知不到。我給內(nèi)存池加了一個(gè)可選檢測(cè)層在池對(duì)象里維護(hù)一個(gè)位圖1 表示該塊已分配0 表示空閑。每次pool_alloc分配一塊時(shí)對(duì)應(yīng)位圖位置置 1每次pool_free釋放時(shí)置 0池析構(gòu)時(shí)掃描位圖凡是仍為 1 的塊就是泄漏塊。這個(gè)位圖方案的優(yōu)點(diǎn)是開銷極小每次分配/釋放只需要修改一個(gè) bitO(1) 時(shí)間。對(duì)池內(nèi)固定塊的數(shù)量沒有硬性限制本質(zhì)上就是用空間換檢測(cè)能力。5.2 把檢測(cè)數(shù)據(jù)導(dǎo)出成可視化報(bào)表工具本身只輸出文本日志但項(xiàng)目組有些人就喜歡看圖。我給工具加了一個(gè)mt_write_report(FILE *fp)接口把統(tǒng)計(jì)數(shù)據(jù)和聚合泄漏數(shù)據(jù)用 CSV 格式導(dǎo)出。然后可以直接在 Excel 里透視圖或者用 Python/Pandas 腳本畫一張“泄漏熱點(diǎn)圖”——每個(gè)文件對(duì)應(yīng)一個(gè)長條條形高度表示泄漏字節(jié)數(shù)顏色表示泄漏塊數(shù)量。這些圖表在周會(huì)上匯報(bào)時(shí)非常直觀能瞬間說服老板“確實(shí)該修內(nèi)存問題了”。CSV 導(dǎo)出格式大致是file,line,leak_count,leak_bytes,total_alloc_count,total_free_count main.c,42,3,1536,1010,1007 network.c,118,1,4096,512,511 texture.c,7,12,24576,1200,1188注意不要把 CSV 的列頭寫得太復(fù)雜保持機(jī)器可讀就好。真要做可視化時(shí)間應(yīng)該花在“從日志里定位問題”上而不是折騰圖表庫。5.3 與項(xiàng)目框架集成的最后一步工具集成到 CMake 項(xiàng)目里非常簡單option(MEMTRACK_ENABLE Enable custom memory tracking OFF) if(MEMTRACK_ENABLE) target_compile_definitions(app PRIVATE MEMTRACK_ENABLED) target_compile_options(app PRIVATE -Wl,--wrapmalloc -Wl,--wrapfree -Wl,--wraprealloc -Wl,--wrapcalloc) endif() target_sources(app PRIVATE memtrack.c)用-Wl,--wrap注意一個(gè)細(xì)節(jié)宏替換已經(jīng)把代碼里的malloc變成了mt_malloc但第三方庫內(nèi)部對(duì) malloc 的調(diào)用仍然指向原始符號(hào)。--wrap只影響原始符號(hào)不影響宏替換后的mt_malloc調(diào)用鏈。也就是說兩套機(jī)制完美互補(bǔ)不會(huì)互相打架。6. 工具能力邊界與實(shí)用的建議這個(gè)工具并不是萬能的說清楚它的邊界可以讓后來者少走彎路。它查不了“未初始化讀取”因?yàn)閮?nèi)存在分配時(shí)被填了 0xCD但 C 類的構(gòu)造函數(shù)可能把這個(gè)值覆蓋掉了檢測(cè)不了“讀到了舊數(shù)據(jù)”。它也不擅長查“并發(fā)數(shù)據(jù)競爭”——那是 ThreadSanitizer 的職責(zé)。它最擅長的是泄漏、越界寫、重復(fù)釋放、釋放后使用這些內(nèi)存錯(cuò)誤里最折磨人的那幾類。根據(jù)我自己的使用經(jīng)驗(yàn)給準(zhǔn)備上手的人幾個(gè)建議別一上來就開全量檢測(cè)。先開“僅統(tǒng)計(jì) 泄漏報(bào)告”確認(rèn)程序能正常跑完再逐步打開越界檢查、釋放后填充這些重開關(guān)。在 CI 跑測(cè)試時(shí)用全量檢查模式跑單元測(cè)試和集成測(cè)試把報(bào)表存檔。連續(xù)對(duì)比幾天的報(bào)表能很早就發(fā)現(xiàn)內(nèi)存回歸。報(bào)告輸出的日志要有明確的級(jí)別。我一般按“錯(cuò)誤級(jí)別”輸出哨兵被破壞是 ERROR泄漏是 WARNING統(tǒng)計(jì)信息是 INFO。這樣在日志系統(tǒng)里可以快速過濾。如果在某個(gè)版本里引入這個(gè)工具后程序反而崩了先關(guān)掉釋放后填充大概率是釋放后仍有讀取操作工具剛好把這個(gè)“臟數(shù)據(jù)”暴露出來了。這是工具在幫你發(fā)現(xiàn)問題不是工具本身的問題。最初把這個(gè)工具集成到項(xiàng)目里時(shí)報(bào)表輸出是純文本的全靠肉眼看。后來發(fā)現(xiàn)真正好用的檢測(cè)工具不是輸出得多而是輸出得“準(zhǔn)”。當(dāng)報(bào)告按文件行號(hào)聚合、按泄漏字節(jié)排序、過濾白名單之后每天打開報(bào)告掃一眼就能知道今天有沒有引入新的內(nèi)存問題。這種“一眼看到變化”的體驗(yàn)是 Valgrind 和 ASan 都沒法輕易給的——因?yàn)樗鼈冸x你的項(xiàng)目太遠(yuǎn)了而自定義工具就住在你的代碼里。最后再分享一個(gè)讓我收獲很大的小技巧工具開發(fā)出來后我故意在一個(gè)測(cè)試文件里寫了幾處 bug——一個(gè)越界寫、一個(gè)泄漏、一個(gè)重復(fù)釋放。然后讓人去查看工具能不能準(zhǔn)確報(bào)出來。這個(gè)“自測(cè)用例”非常有用每次給工具加新功能我都能快速回歸一遍確認(rèn)沒有把之前的檢測(cè)能力弄壞。內(nèi)存檢測(cè)工具本身也是軟件它也需要測(cè)試。