bug定位過程：
char *wr_pr_debug_begin(u8 const *data, u32 len, char *string)
char *wr_pr_debug_end(char *string)
void test()
考驗基本功的時候到了，熟悉函式呼叫傳參的人應該會知道編譯器一般對引數的處理採用堆疊的方式，是乙個先進後出的過程，這樣引數的執行一般是逆序的（由於編譯器實現的不同，這個過程不是確定的），這樣kfree會在kmalloc之前執行，導致每次執行都會洩漏一點記憶體。上面是乙個debug輸出，暫時注釋掉後壓測，問題解決，記憶體保持穩定。
總結：整個定位過程其實比較簡單，如果第一步看下/proc/meminfo可能會更快的定位問題（由於這個kernel driver是「大廠」提供，以為不會出問題，一直從上層的角度去找問題，所以沒有太關注kernel相關記憶體的使用），導致記憶體洩漏的原因也很簡單，出現這種問題的原因，首先編寫者的基本功一般，更主要的原因是編寫者出於「炫技」的方式去寫了這段**，如果老老實實封裝乙個debug函式，按照正常順序呼叫也就沒有問題了，而且這種每次列印進行kmalloc的方式，對效能也是有些影響的。總之基本功還是很重要，而且不要駕馭自己駕馭不了的編碼方式。
kernel記憶體洩漏的除錯
boot kernel lib kconfig.debug 修改config debug kmemleak early log size中default 400為4000，因為400會洩漏，kernel呼叫log early剛好401次，剛剛把400次耗光，導致log early中滿足crt ear...
記一次goto記憶體洩漏
學習c語言時一直被告誡盡量不要使用goto語句，所以對其了解很少。在一次專案使用時由於之前的程式已經使用了goto，按照自己的理解去處理，結果導致記憶體未釋放。例子如下 include int main return 0 error printf aaaaa n printf 11111.n ret...
記一次排查記憶體洩漏的過程
排查過程 程式測試執行過程中，其中乙個程序被linux系統給殺掉了，檢視系統日誌，發現是進行占用記憶體過大而觸發linux oom給殺掉了。重啟反覆幾次後均被殺掉，發現是記憶體洩漏問題。另發現有的時候有記憶體洩漏，有的時候沒有記憶體洩漏。針對這種情形，首先想到的是進行重現，然後使用工具檢測排查，同時...