一個驅動致使的內存泄漏問題的分析過程(meminfo->pmap->slabtop->alloc_calls)

關鍵詞：sqllite、meminfo、slabinfo、alloc_calls、nand、SUnreclaim等等。

 

下面記錄一個因爲驅動致使的內存泄漏問題分析過程。

首先介紹問題背景，在一款嵌入式設備上，新使用sqllite庫進行數據庫操做，在操做數據(大量讀寫操做)一段時間以後，發生OOM現象。

而後OOM會選擇進程kill，即便系統中不剩什麼進程，仍然內存緊張。

下面就介紹從上往下查找問題，而後在底層掐住RootCause，進而解決問題的分析過程。

1. 問題初步分析

首先懷疑的是sqllite庫問題，在PC進行一樣的測試未發現內存泄漏。在另外一款參考設備上，進行一樣的測試，未發現內存泄漏。

以上測試確保了測試程序、sqllite庫等一致，僅交叉工具鏈和平臺不一致。

結論：能夠基本確定sqllite庫以及測試程序沒有問題，可能的問題包括交叉工具鏈、平臺問題。平臺問題更大，因此問題集中到具體平臺上進行分析。

疑問點：

1. 爲什麼進程退出後，泄漏的內存沒有釋放？參見分析，是由於SUnreclaim的slab內存不在進程內存統計範圍以內。

2. 是否因爲工具鏈不一樣致使庫函數表現不一致？參見分析1，內存泄漏點在內核驅動中。 參見分析2，通過在RAM上運行sqllite測試；單獨測試NAND文件系統，得出泄漏和sqllite無關。

3. 是平臺內核致使的泄漏嗎？參見分析，肯定泄漏在kmalloc-4096這個slab中。

2. 具體平臺查找內存泄漏方向

定位內存泄漏按照從大到小的思路，即首先看系統內存哪裏泄漏，而後再看進程內存哪裏泄漏，最後看哪一種內存泄漏。

2.1 分析系統內存

首先經過cat /proc/meminfo，而後分析泄漏點。

從MemFree和MemAvailable看，內存將低了235M和228M。

而後看一下下面內存消耗在哪裏？能夠看出slab消耗了228M，再細節能夠看出SUreclaim消耗了228M。基本肯定

結論：肯定因爲Unreclaim類型的slab泄漏致使的內存泄漏。

疑問點：找出具體哪一個slab泄漏了？參見分析，在kmalloc-4096這個slab中。 哪一個調用的slab申請？參見分析，經過kmalloc-4096的alloc_calls能夠知道調用點。

2.2 分析進程內存

經過pmap -X -p `pidof xxx`來獲取進程的地址映射空間，能夠分析進程內存細節。

結論：經過下面的對比，能夠看出進程自己沒有致使內存泄漏。因此內存泄漏雖然有此進程致使，可是泄漏點不在進程中。

2.3 分析slab內存泄漏點

既然肯定slab致使的泄漏，那麼就須要使用slabtop、/proc/slabinfo以及/sys/kernel/slab來分析。

從下面能夠看出泄漏點在kmalloc-4096這個slab，這個slab消耗的內存爲250M左右。

而後就是去找slab的調用記錄，幸運的是系統在/sys/kernel/slab/*/中提供了alloc_calls和free_calls。

alloc_calls:
      1 pidmap_init+0x4e/0x10c age=418000 pid=0
      1 con_init+0xf6/0x21c age=418007 pid=0
      1 pcpu_mem_zalloc+0x36/0x74 age=417641 pid=1
      1 seq_buf_alloc+0x26/0x54 age=0 pid=349
      1 register_leaf_sysctl_tables+0x74/0x1b0 age=418000 pid=0
      1 ubifs_mount+0x68/0x15e8 age=416589 pid=1
      1 ubifs_mount+0xdaa/0x15e8 age=416588 pid=1
      1 nand_scan_tail+0xa2/0x6a8 age=417469 pid=1
      1 ubi_attach_mtd_dev+0x9a/0xc38 age=417168 pid=1
      1 sourcesink_bind+0x382/0x4c0 age=417588 pid=1
      1 vid_dev_probe+0x32/0x1a0 age=417569 pid=1
      2 hantrodec_probe+0x56/0x944 age=417502/417512/417523 pid=1
  55898 spinand_cmdfunc+0x236/0x52c age=8997/225988/416514 pid=1-202
      1 flow_cache_cpu_prepare.isra.7+0x3c/0x74 age=417889 pid=1

free_calls:
  55840 <not-available> age=343019 pid=0
     59 kvfree+0x2a/0x60 age=0/239003/415431 pid=140-349
      1 ubifs_read_superblock+0x690/0xe14 age=416600 pid=1
      8 kobject_uevent_env+0xda/0x580 age=416605/417396/417653 pid=1
      3 uevent_show+0x5e/0xf4 age=409638/411302/413798 pid=143-150
      1 skb_free_head+0x2c/0x6c age=417902 pid=1

結論：從alloc_calls能夠看出spinand_cmdfunc中申請了55898次slab，和系統內存泄漏量基本一致。

2.4 分析驅動內存泄漏

經過objdump -S -l -D vmlinux > vmlinux.txt，而後結合反彙編代碼，找到spinand_cmdfunc+0x236能夠找到具體點。

805829e2:       e3f26433        bsr             0x803cf248      // 803cf248 <_end+0xff997448>
805829e6:       c4004820        lsli            r0, r0, 0
spinand_cmdfunc():
/home/al/deepeye1000/linux/drivers/staging/mt29f_spinand/mt29f_spinand.c:806 spinand_program_page(info->spi, state->row, state->col,

因此問題最終指向了mt29f_spinand.c的806行，spinand_program_page()這個函數裏面。

分析此驅動代碼，能夠看出經過devm_kzalloc()申請的內存沒有被釋放的點。雖然此內存在模塊卸載的時候會被自動釋放，可是NAND驅動通常不會被卸載。

結論：肯定泄漏點在spinand_program_page()中。

3. 旁證測試

基本上找到的問題點，爲了驗證上述分析作了幾個簡單的測試。

3.1 在ramfs中進行sqllite數據庫操做

既然泄漏點在NAND驅動中，那麼避開在NAND中進行讀寫操做便可。在/tmp目錄下，進行數據庫操做，做爲對比測試。

一樣的軟件和平臺下，運行一樣的業務。

結論：在ramfs中進行操做，沒有發生內存泄漏。說明泄漏sqllite操做無關。。

3.2 在NAND上進行文件cp、rm等操做

既然泄漏點在NAND，那麼不使用數據庫讀寫，純文件系統讀寫如何呢？

通過測試，一樣發現SUreclaim內存增長致使的泄漏。

結論：內存泄漏跟NAND上文件操做有關。

爲何以前沒有發現內存泄漏問題呢？原來主要業務是運行應用，不多對NAND進行寫，即便有寫也是偶爾的，發現不了內存泄漏。這種狀況在頻繁的讀寫、刪除操做下比較容易復現。

4. 解決問題

解決的思路就是確保在函數退出的時候，保證wbuf的內存可以獲得釋放。

diff --git a/drivers/staging/mt29f_spinand/mt29f_spinand.c b/drivers/staging/mt29f_spinand/mt29f_spinand.c
index 2474d88..7042934 100644
--- a/drivers/staging/mt29f_spinand/mt29f_spinand.c
+++ b/drivers/staging/mt29f_spinand/mt29f_spinand.c
@@ -495,7 +495,8 @@ static int spinand_program_page(struct spi_device *spi_nand,
 #ifdef CONFIG_MTD_SPINAND_ONDIEECC
     unsigned int i, j;
 
-    wbuf = devm_kzalloc(&spi_nand->dev, CACHE_BUF, GFP_KERNEL);
+    wbuf = kzalloc(CACHE_BUF, GFP_KERNEL);
     if (!wbuf)
         return -ENOMEM;
 
@@ -509,7 +510,7 @@ static int spinand_program_page(struct spi_device *spi_nand,
         retval = spinand_enable_ecc(spi_nand);
         if (retval < 0) {
             dev_err(&spi_nand->dev, "enable ecc failed!!\n");
-            return retval;
+            goto exit;
         }
     }
 #else...
-
-    return 0;
+exit:
+#ifdef CONFIG_MTD_SPINAND_ONDIEECC
+    kfree(wbuf);
+#endif
+    return retval;
 }

5. 驗證測試

基於以上的分析過程，構建測試用例：

1. 進行一樣的NAND上sqllite數據操做

2. 一樣重複cp、rm操做NAND上文件系統