1.檢視記憶體使用情況
cat /proc/meminfo
其中sunreclaim:695168 kb,隨著測試時間加長sunreclaim一直在增加，證明存在記憶體洩露可能.
２.檢視slab分配資訊
cat /proc/slabinfo
其中skbuff_head_cache和kmalloc-1024分配的object數量達到8萬個以上，而且還在不斷增加，懷疑skb有記憶體洩露.
由於sysfs檔案系統一次只能輸出page_size大小的資訊，導致 cat alloc_calls只能輸出部分資訊.而且也沒有顯示分配的呼叫堆疊
通過增加除錯資訊，過濾分配較少的slab輸出，新增alloc stack資訊.
跟蹤到分配最頻繁的呼叫棧為
cat /sys/kernel/slab/kmalloc-128/alloc_calls
84050 __alloc_skb+0x68/0x1b4
[4]__alloc_skb+0x68/0x1b4
[5]tcp_send_ack+0x68/0x154
[6]__tcp_ack_snd_check+0x64/0x108
[7]tcp_rcv_established+0x364/0x740
[8]tcp_v4_do_rcv+0xa8/0x1b8
[9]tcp_v4_rcv+0x808/0xbd0
[10]ip_local_deliver_finish+0x1dc/0x370
[11]ip_local_deliver+0xe0/0x10c
[12]ip_rcv_finish+0x348/0x3e8
推測系統沒有正確釋放tcp ack包，而wifi驅動支援dhdtcpack_suppress功能。
直接看wifi驅動hard_start_xmit函式對tcp ack報文的處理邏輯
分析了dhd_tcpack_hold函式，當tcpack_info_tbl都被占用時，此時再來乙個其他ip的tcp ack,
會hold,而又沒有新增到tcpack_info_tbl ，從而導致tcp ack丟失。
bool
dhd_tcpack_hold(dhd_pub_t *dhdp, void *pkt, int ifidx)
else
dhd_os_tcpackunlock(dhdp, flags);
exit:
return hold;
}如果發現是kmalloc-128 分配的object個數大，需要減少kmalloc的粒度再測試
#define arch_kmalloc_minalign 8 //最小分配為8 byte
#define kmalloc_min_size 8
#define kmalloc_shift_low 3
解決記憶體洩露的問題，也可以用kmemleak 排查。配置 config_debug_kmemleak，並在 cmdline 中加入 kmemleak=on
DEBUG 記憶體洩露除錯
呼。又是一次痛苦的除錯經歷，趕緊記點心得吧。雖然是乙個很傻x的失誤，但是經歷的過程還是收穫蠻多的。開始之前，順便透露一下，關於shero，我已經決定做乙個單機開源rpg了，最遲在5月發布吧，最終效果相信不會令大家失望。好了，起因是這樣的，因為整合了cegui，介面基本搭好時，卻發現有嚴重的記憶體洩露...
iOS SN Xcode記憶體洩露除錯
用xcode進行記憶體除錯有兩種方法 1 靜態方法 2 動態方法 靜態方法是直接在xcode的選單欄中選擇product analyze 如截圖所示。提示有可能有多少洩露物件，這裡還沒有編譯完，提示有199個，然後再如下圖所示 就會看到具體的提示，有的提示會有潛在的洩露物件，有的提示垃圾物件，或者值...
記憶體洩露分析
記憶體洩露分析demo gflags標誌設定好後，開啟cmd 鍵入要定位記憶體洩露的程式gflags.exe i memroyleak.exe 程式名稱 ust 如圖成功後，開啟memoryleak.exe程式 命令格式 umdh pn memoryleak.exe 程式名稱 f snap1.log...