查找bug原因的一些个人经验

今天知乎看到别人问《老程序员解bug有那些通用套路?》 就总结了下自己的方法,回答了下。罗嗦了不少字,就摘出来了。


个人经验和操作:

根据实际情况步骤会有跳过和循环。

1. 弄清楚环境

  • 1.1 对于客户端和偏硬件的,环境影响很大的,可能是某地方兼容没做好,或者直接没支持。

  • 1.2 对于 server 端, 依赖的的内核或者某个dll版本不对,功能异常或者直接崩溃都有可能。

  • 1.3 弄清楚环境也是必现必须的,因为可能实际机器没有开发机器配置高也会有莫名的问题,一不小心高估板子的能力,你在模拟环境怎么都不会必现的。

2. 问清楚操作(访问的接口),和 输入输出

  • 2.1 根据操作和访问的接口,才能知道问题大概的位置,和其依赖的模块

  • 2.2 弄清楚数据,才能去做模拟和复现

3. 确认业务逻辑

  • 3.1 对于有些操作,要先确认业务逻辑是否理解的正确,这是解决问题的关键,由于沟通和经验,定位不一样,对同样的东西理解是有偏差的,一点逻辑偏差,不确认的话,一直沉溺在自己的理解,是不可能准确定位到问题的。

  • 3.2 何况有些时候是你接手的代码,本来就一头雾水,如果代码写的乱,不清楚逻辑就没法搞了。

上面 是准备工作,下面就要真正去确定问题的原因了。

如果代码都是自己写的,基于上面准备工作弄清楚了,如果是逻辑问题,那么你心里应该有个数了,就是不确定,也应该大概确定到问题可能出现在那块代码了。

4. 静态分析可能出问题的代码

  • 4.1 如果代码是自己写的,在心中模拟整个代码执行流程。个人经验,很多问题其实就是一个不小心代码写错导致的问题,例如变量名弄错(重用),逻辑太复杂,一个判断条件出问题,使用错误的api,或者少处理了一种情况。静态分析下自己的代码,可能有一半的bug,其实已经解决了。如果解决不了,也应该知道就是接着处理,在哪里断点 和 加日志也都有数了。

  • 4.2 如果代码不是自己写的,核对代码执行逻辑,确认关键点。别人同样会犯自己犯的错误。在静态分析中也顺便梳理下别人的思路,找出关键点。便于下步操作。

4.5 对于段错误我的一般处理

对于段错误,这个太正常,而且不好处理。我的一般处理是,直接debug运行(gdb或者IDE中debug),不加断点。 等其崩溃,然后查看堆栈信息。当然有core文件,就可以直接查看堆栈信息了,然后根据堆栈去静态分析。 如果是必现,每次位置一样,那么静态分析90%都处理了,不用log和断点那么麻烦了。如果每次位置不一样,或者不必现,那么一般都是线程安全搞鬼了,不好查,先梳理下共享的变量吧。

5. log 和 断点

  • 5.1 如果有条件,断点最好,更直观。对于 server 和 偏硬件的,不好直接断点的,就只能日志了。其实都是获取执行过程中的状态。

6. 等等吧 和 甩锅吧

如果上面你还定位不到问题,那么可能是下面情况了:

  • 6.1 思维走入误区了,那就放放吧,转手忙点其他的吧,过会在回来想,可能就豁然开朗,找到问题了。

  • 6.2 不是现在的我能解决的,老实去求助吧。google, 同事, 群里大牛们。如果是请教人,** 注意先描述清楚直接问题,环境 和 操作。 ** 至于你自己的分析和猜想,可说可不说,最好是说下,但是必须在上面的前提下。注意X,Y问题,** 不要把你猜想和分析遇到问题当作问题去问! **

  • 6.3 可能真不是你的问题,依赖环境问题,这个就要去查资料确认,能找到源头最好。找不到反正你模拟没问题,先拖着呗。


上面罗嗦一大堆,都是查找问题的,至于解决问题,找到原因了,还有解决不了的问题?不能直接解决,绕着走啊。

其实楼上简单的总结很到位的,其实几个字的事: 调查->分析(猜)->验证。

罗嗦一大堆都是个人具体操作的经验。不一定对和适合所有人。如有错误,请大牛们指正。

One thought on “查找bug原因的一些个人经验”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.