调试Linux驱动Bug的思路总结

    2017年一年的工作，大部分做的解码器驱动相关的工作，由于硬件也不会有太大的变化，主要是优化和增加新规格，毕竟很成熟的东西你去改它何必呢？所以驱动也不会太大改变，最近一年的代码量输出的比较小，主要是调试驱动，解Bug。一年下来解了小说100来个Bug吧~~，当然还有很多问题单是非问题，也花了不少精力澄清。

    调试驱动，解Bug，任务主要来源是自己测试发现的Bug，测试部测出来的Bug，客户提出来的Bug，有时候量产关头，有些问题来的异常紧急，或者有些问题很诡异，涉及复杂的场景，多个模块，复现概率又低的情况下，就需要一定的技巧了。下面总结一下过往一年调试驱动的经验。

    1.信息收集。一些蛛丝马迹都很重要，一旦思路进了歧途，就有可能浪费掉很多时间。看log，看内核态串口的打印，logcat看用户态的打印，堆栈信息，相关驱动proc，内核运行状态的proc，包括测试人员的口供，如何触发问题，复现概率等。

    2.数据处理。根据收集过来的信息，进行分析，这里就好比写作文之前的构思，往往90%的Bug都可以在这个阶段分析出具体原因，至少可以确定引起异常的代码段和场景。

    3.代码分析。就去走读代码啦。结合分析的过程，推测是否存在种种可能，如果推测合理，可以修改代码和加打印进行验证。

    4.场景拆解。如果Bug比较难复现，又没有具体思路，就要尝试提高复现概率，把复杂的场景缩小成简单的场景，这样容易确定案发现场。

    5.头脑风暴。结合上面所有的信息，推测各种可能，和怀疑的地方。咨询更有经验的同事，一起讨论。

    6.结论验证。修改代码，并且加上打印，验证自己的结论。

    一年来，从最开始面对一坨无从下手的代码，到现在通过日志加上迅速走读代码，80%的Bug都很快解决掉，当然，那些恶心的踩内存死锁栈溢出这些问题，还是相当难搞。