还是周末
我也不想说周末，但是不是周末的话，可能也没有特别清净的时间来处理困难的问题。这周末我是要加班的，加班的前一个晚上，我领导找我们吃了一个便饭，聊了很多东西，这篇文章我就不说了，会在下篇文章来讲这个事情，这篇文章就讲修复的内存溢出的问题。
问题出现的现象
现象是我们测试发现，晚上在不断的运行后会出现重启，而且是每隔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。
