Bug描述：壓力測試一個小工程時發現記憶體逐漸減少，10個小時後出現OOM

Bug定位過程：

• 對整個工程模組進行分解，逐步縮小範圍，由於整個工程包括幾個相對獨立的小模組，而整個工程採用單程序多執行緒的模型，導致進行分解時，要特別注意相互之間的耦合，只能逐步分離各個模組，執行測試（這裡如果採用多程序模型，定位會更快一些，一個完整的功能，放在一個程序和多程序中，多程序天然的將功能細化了，定位問題，範圍更小）
• 在經過一段折磨人的拆分過程後，最後把問題定位到整個工程中一個小模組功能內。在對該模組進行了反覆的程式碼review後，沒有發現什麼異常，甚至沒有記憶體申請的操作。
• 程式碼層面沒有找到突破的情況下，重新通過各種命令查看了記憶體狀態，由於在此之前一直通過free命令檢視記憶體，發現長時間後free命令輸出的可用記憶體在逐漸減少，但忽略了一點：通過top命令單獨檢視模組程序佔用的記憶體時，該程序的rss段一直保持穩定，沒有大幅度增長。
• 基於前一步的發現，懷疑是kernel的記憶體有洩漏，檢視/proc/meminfo發現一個疑點：slab記憶體佔用很高，且SUnreclaim的slab一直在增加，此時基本確定kernel記憶體洩漏。
• 通過kmemleak對核心記憶體進行了分析，定位在到一個函式介面中：

char *wr_pr_debug_begin(u8 const *data, u32 len, char *string)
{
    int ii;
    string = kmalloc(len * 2 + 1, GFP_KERNEL);
    for (ii = 0; ii < len; ii++)
        sprintf
 
(&string[ii * 2], "%02X", data[ii]);
    string[len * 2] = 0;
    return string;
}
char *wr_pr_debug_end(char *string)
{
    kfree(string);
    return "";
}
void test()
{
    char *read = 0;
    pr_debug("%s RD%02X%02X%02X -> %s%s\n", st->hw->name,
         i2c_addr, reg, length,
         wr_pr_debug_begin(data, length
 
, read),
         wr_pr_debug_end(read));
}

一眼可能不容易看出上面的有什麼問題，有kmalloc，有kfree啊，好像成對出現的。
考驗基本功的時候到了，熟悉函式呼叫傳參的人應該會知道編譯器一般對引數的處理採用堆疊的方式，是一個先進後出的過程，這樣引數的執行一般是逆序的（由於編譯器實現的不同，這個過程不是確定的），這樣kfree會在kmalloc之前執行，導致每次執行都會洩漏一點記憶體。上面是一個debug輸出，暫時註釋掉後壓測，問題解決，記憶體保持穩定。

總結：整個定位過程其實比較簡單，如果第一步看下/proc/meminfo可能會更快的定位問題（由於這個kernel driver是“大廠”提供，以為不會出問題，一直從上層的角度去找問題，所以沒有太關注kernel相關記憶體的使用），導致記憶體洩漏的原因也很簡單，出現這種問題的原因，首先編寫者的基本功一般，更主要的原因是編寫者出於“炫技”的方式去寫了這段程式碼，如果老老實實封裝一個debug函式，按照正常順序呼叫也就沒有問題了，而且這種每次列印進行kmalloc的方式，對效能也是有些影響的。總之基本功還是很重要，而且不要駕馭自己駕馭不了的編碼方式。