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