還是周末

我也不想說周末，但是不是周末的話，可能也沒有特別清凈的時間來處理困難的問題。這周末我是要加班的，加班的前一個晚上，我領導找我們吃了一個便飯，聊了很多東西，這篇文章我就不說了，會在下篇文章來講這個事情，這篇文章就講修復的內存溢出的問題。

問題出現的現象

現象是我們測試發現，晚上在不斷的運行后會出現重啟，而且是每隔1個小時左右就會重啟。

然后我們拿到了日志分析，發現每次重啟前都會出現 Out of memory，這里感謝guanxi同學，我那時候還沒有注意，他給我指出來了。

OOM會導致系統把占用內存最大的進程給kill掉，如果連續3次OOM，就會導致重啟。

當然，你也可以設置閾值來修改這些配置，如下，可以修改觸發OOM的門限

echo?-100 > /proc/$PID/oom_score_adj

分析問題

因為每次出現后都是會干掉我們的應用程序，我們先把應用程序分析了一遍，最后發現把我們的應用程序干掉還是會出現內存溢出。

export?TERM=linux htop

關于htop的用法大家可以去自己體驗一下，里面有非常多的配置，可以看到很多關于系統的內容。

在htop界面，可以清晰的看到內存一點一點的增加。

所以，不是應用的問題。

系統部分分析

然后我回退代碼，發現是一個HID的修改增加導致的，這個修改是和HID增加mute相關的。

再觀察日志的時候，在正常的情況下，內核不會反復打印某條日志。

然后就用上了抓包工具wireshark,這個工具不僅可以抓網絡包，還可以抓USB包。

抓到包后，發給我的同事輝哥，輝哥分析后是因為代碼里面沒有對這種異常情況進行判斷。

so,加上這部分的判斷就可以了。

非常感謝guanxi給我們提供了另外一種USB抓包工具

如果大家想獲取，可以在公眾號后臺回復「USB抓包工具」

關于這個問題的一些思考

剛開始我想找到某個線程的內存異常，但是線程的內存和進程是共享的，所以一個進程開了20個線程，每個線程體現的都是進程的內存大小，看起來并沒有差異。而且我在查看進程內存的時候，發現進程的內存并沒有增加，這時候我就應該轉變方向了。

rockchip的很多代碼寫的都很好，但是在實際的應用場景上，會遇到各種各樣的問題，我們這次的修改，也是因為在這款設備上面出現的差異，在其他設備上是沒有問題的，但是要想去排查所有的硬件差異后根除，那可能比修改代碼更加困難。

抓日志分析一定是最好的解決問題的方式，在遇到問題前，還是要先找出問題差異點，從差異點去分析。

最后還是輝哥，yyds。

總結

以上是生活随笔為你收集整理的辉哥给rockchip修复了一个内存溢出问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。