面对无头绪的Bug，该怎么办？

软件或者驱动开发过程中，有些bug可以很容易的抓出来，但是有些隐藏的很深，只是在某些条件下才会触发产生，这种bug，真是 ugly pest ！！

简单的Bug，一般来说都是"single process"的，即只处理一个简单的事情，涉及的软件资源【函数】和硬件资源【buf，外设】不多，那么问题就比较容易定位；

复杂的bug，一般来说Process是复杂的，用的资源也比较多，“复杂过程 + 多资源占用”会让trace analysis过程无从下手，到处都是线索，到处又都是不全的线索。

这个时候，一个高级工程师和一个菜鸟工程师的功底差异就体现出来了。

高效的逻辑思维，是一个高级工程师解决问题时候必备的，也是唯一的利刃，很明显，面对一个bug，你不可能“精通”与bug有关所有软件和硬件，在此情景下，“分析推理能力”是快速切入问题，trace问题根源的最高效的办法。

所谓的“分析推理”，

   （1）就是先看“线索”-------- 呈现出来的异常现象，异常的log ----- 做出初步推断，有哪些可能的原因？cause0---cause1-----cause2.........；

   （2）然后就是要知道“我能相信该问题有关的哪些资源”，这个是很关键的，因为胡乱的怀疑，会让问题更加复杂和不确定，变得千头万绪，大大影响分析、解决问题的速度；

   （3）验证你怀疑的cause，验证cause也很有意思，比如你怀疑某某硬件有问题，那么你就不要在当前情景下验证，这样即使有坏的结果，也不知道是不是硬件本身还是使用硬件的软件出了问题，最可靠的方法是“裸验证”，即独立测试该硬件

   （4）排除各个资源的单独问题后，就是综合分析交互影响了，分析交互影响的手段一般有几个：一个是画出清晰的Process Timing,这个非常重要，还有就是画出各个部分（软件和硬件）的可能影响； 基本上结合问题的现象和log信息，问题root cause很快会浮出水面！

 

有了这套“渔”，就别怕千奇百怪的Pest，世上没有灵异事件，有的只是常规思维下的“奇怪”结论罢了，所有的bug都有root-cause，找bug，就是把所有怀疑的全部验证完，剩下的就是那个叛徒了。

当然，由现象推断原因，由表及里的逻辑功力，是必备素质。