大家所谓的偶发性问题，就是很难复现、较难定位的问题，比如在家里验证了N遍，固件一发布到客户现场就各种宕机；现场刚调试得明明白白，正准备离开客户公司大门，客户来电话了，然而折返复现问题，却死活不出现；明明有些代码“对天发誓”不会存在问题，而程序运行久了总有概率在那一块翻车，等等。
确实遇到这样的问题属实让人头皮发麻，比如你在深圳，客户现场在北京，出了一些偶发性问题，很多朋友心里想要是能飞过去插个仿真器那这些bug不是分分钟的事情吗？其实也不是不可能，远程仿真工具嘛~最怕客户现场没有网络~
不过问题是有些bug不是随随便便给你面子复现的，甚至它隔个好几天问候一下你，总不能可能一直干等吧。
那么，对于这样的偶发性问题，我们到底该如何解决呢？首先我们要充分的了解和把握出现问题的情景，比如问题出现时，是否客户做了什么操作、是否有停过电、大概在几点出现的、是否存在一定的规律、如果现场有多台机器，他们是否都会出现类似的问题等等。只有充分了解了问题现场的详细发生情景，你才能快速的排除一些问题、缩小定位的范围，最重要的是分清楚到底是软件问题，还是硬件问题？我见过很多老实巴交的软件朋友一遇到问题就打开工程查软件bug，那只会让我觉得你头秃是有原因的。同时也要对所收集的信息进行一些筛选和排除，因为一个现象对于不同的人会有不同的描述，有些客户并不是专业人士一些现象描述得不清楚，有可能把你带入误区。所以结合系统日志信息、目前设备状态和售后或者客户描述，进行初步的问题定位。
很多朋友了解了具体的问题以后就抱着猜一猜的心态，凭感觉去修改代码，如果问题不再出现就认为是修护了该问题，这样的做法是不科学的。作为一名工程师还是要本着务实求真的态度，一步一步的缩小问题的范围，通过安插测试程序来检测难以复现的偶发性问题，让工程师来主动查找bug，还不如安插一些bug捕捉程序来自动监测bug，这样也会更加的精准。多模拟一些问题出现频率较高的环境和状态，比如有一个问题专门在晚上发生，那么我们可以构建一个晚上的环境，比如系统时钟的调整、系统访问用户的增加或者晚上的一些特殊操作等等。从而进一步降低复现问题的成本。
很多朋友已经习惯了用仿真器来进行问题的排查，确实仿真器几乎暴露了系统运行的所有状态，再加上一些条件断点、查看工具等的加持，bug基本上跑不了。在产品开发的前期阶段，这样的开发和解决问题方式是高效的，但这样的愿景在真正的产品上线以后是比较难实现的，比如一些防水密封或者大型的设备等。所以，还是要借助一些其他手段帮助我们分析问题，依靠一些通信协议把相应的数据传输出来进行分析。打印日志信息是大家经常想到的，也是一种老牌调试办法了~对于大部分对时间要求不敏感的问题是最合适的调试手段了；如果是离线运行的话，可以找一片存储区，比如Flash或者SD等，或者自带文件系统的可以直接写到文件中，以便后续拷贝或者上传出来进行分析。然而日志打印比较耗时，对于很多偶发性问题，可能就是一闪而过的事情，而且最可怕的莫过于你的日志打印里面也有bug，所以寻找一个越简单越好。直接通过构造问题出现的判断条件，然后赋予不同的调试变量不同的标识，当问题出现以后进入并保存相应的信息到调试变量中，最终接上上位机就可以看到，简单直接。然而，有些降成本的产品连个通信都没有，那该怎么玩呢？Led、IO口你值得拥有，他们都可以通过高低电平的状态来传递信息给外界，如果你够狠的话，还可以自己定义一套单总线通信协议。
当然还有一种是直接死机了，这种问题是比较头疼的，如果只是像hardfault这样的可循异常，倒可以在死机前进行现场环境保存工作。同样对于直接复位的情况，大家也可以在程序入口地址处通过打印相关的信息来供分析，比如寄存器的值等内存信息，来回溯到之前的复位点。但是，对于程序既不运行也不复位的情况，就没那么好处理了，很多人会想到实时的记录一些变量和可疑条件等等，也未尝不是一种办法把，大概率还是会漏检。不过，这种情况下大概率还是跟硬件脱不了干系，务必先排查电源电压、功率等干扰问题，再考虑采用屏蔽二分法进行排查代码~好了，基本上调试偶发性bug就这么多分享了，希望这篇文章能对大家有所帮助。来源：最后一个bug
版权归原作者所有，如有侵权，请联系删除。
▍推荐阅读
我用这个技术，干掉几千行if else！
麒麟9000s，并非来自SMIC，而是...
程序员最容易读错的单词，听到status我炸了
