遇到了嵌入式linux下面系統級記憶體洩露問題。跟蹤問題日誌。
平台：arm9
核心：2.6.22
問題：execl造成系統記憶體減少，通過cat /proc/memoinfo 發現少的記憶體並且都移往slab中去了
測試**：
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main()
else if (pid == 0) //child
else
printf("%d\n", i); }
return 0; }
20091011:通過1000此呼叫之後，通過cat /proc/slabinfo對比發現，變化最大的是
name : tunables : slabdata
size-256 120 120 256 15 1 : tunables 120 60 0 : slabdata 8 8 0
size-256 1120 1125 256 15 1 : tunables 120 60 0 : slabdata 75 75 0
計算，pagesperslab為1，即乙個page中有乙個slab，（75－8）×4k ＝ 268k左右。為了排除其他部分造成的記憶體洩露。做了乙個測試，頻繁的進行1000次malloc和free，發現size-256項也無特別變化。可以初步判斷，應該是size-256塊slab中出現了記憶體沒有釋放的行為。下一步動作，研究源**do_execve部分來看分配192～256k的記憶體的嫌疑函式以及是否在退出後被釋放。
20091012:為了排除slab本身有bug的情況，將核心分配機制改為slub，結果，依然在執行1000次之後少出300k的記憶體空間。在slub.c中，static struct kmem_cache *get_slab(size_t size, gfp_t flags)函式中插入log，這裡是分配的必經之路。當分配的大小在128～256之間時，log出分配的size大小。執行測試程式，發現
_debug: get slab size = 192
_debug: get slab size = 208
就是說有分配192和208的需求在。
而簡單的ls，或pwd都會列印這個出來，本人據此推斷，分析進行shell命令也會有記憶體洩露問題。手動ls100次，果不其然，大概有52k的記憶體洩露，平均起來就是2個256的空間沒有收回。
對log的出處一直跟蹤（callstack），發現最終鎖定在load_elf_binary這個函式中，仔細看了code，發現log不是很規範，與同事交流了，原來被touch過。立即找到kmalloc和kfree的地方，看哪個kfree有沒有漏掉，果然發現漏洞。去對比2.6.22歷史版本，發現同事的修改有個地方忘記free了，興奮之餘，趕緊改過來，測試5000次。結果正常。原來這個新增的code是同事用來除錯用的，忘記砍掉了。我說呢，核心應該沒有這樣明顯的錯誤的，google也無任何關於此的問題。經過此次跟蹤後，對核心記憶體分配更加理解。
記憶體洩露檢測
c 中檢測記憶體洩漏可以引入系統定義的巨集來檢視，內存在哪個位置洩漏 檔案開始處加入下列定義 define crtdbg map alloc include include 程式退出時加入以下函式 crtdumpmemoryleaks 如果有洩漏會顯示 記憶體洩漏是程式設計中常常見到的乙個問題，我所...
檢測記憶體洩露
程式結束時,作業系統會 程式占用的資源.但是,只要程式還在執行,如果不進行清理,資源最終可能被耗盡.1.vc記憶體洩露檢查工具 visual leak detector 現在已知的最新有2.0版本的，使方法不詳。使用 visual leak detector 2.2.3 在vs工程的linker i...
記憶體洩露檢測
1 包含標頭檔案 include include 2 每個cpp檔案包含 static char this file file define new new normal block,this file,line 3 設定標誌 int tmpdbgflag tmpdbgflag crtsetdbgf...