怎样解决bug

阅读bug、分析bug、解决bug的过程是对一个程序员的终极考验。

解决bug的步骤：
复杂的bug一定要写下来。动手写！！！
1、复原问题情境。出现了什么bug、在哪里出现的、期望的行为是什么、实际行为是


什么、实现该行为的依赖条件是什么等
2、进行演绎推理，推出bug原因。
3、解决bug。
第一、二步很容易出现问题。如复原问题情境不准确、演绎推理跳跃等。

注意异步操作完成时间的不确定会导致bug。

《转载》

在产品开发过程中，我们每个开发人员调试程序 方法的科学性、有组织性直接影响到工作效率和进度。抓紧和利用一切时间是一方面，而得当的调试思维方式和调试方法尤其显得重要。

 

好的调试思路和步骤，如同抽丝剥茧，层层推进，富有实效，事半功倍；而在条理逻辑不甚清楚的调试思路下，如同没有目标的轰炸，抓不住问题的实质，可能使问题成为顽疾，久攻不下，事倍功半，身心疲惫，疲劳的开发人员伤不起啊。因此，有时碰到比较疑难的问题，首先不能乱，不能急躁，不要紧张，要保持清醒的条理和逻辑。有时不妨脱离计算机，借助一张白纸、一支笔思考一下，仔细分析一下所有的原因，然后逐一排除之。

 

 以下是我建议的步骤，大家感兴趣的话可以参考：

 

 必须精确地记录现象及其发生的环境

 最好用一个记事本，对大脑的自信永远比不过烂笔头嘛。

 

 先做完常规意义的debug

 debug可以有很多灵活的技巧：

 1.最基本的单步和断点；

 2.Watch变量；

 3.看内存；

 4.打印语句或打印变量值；

 5.打印出某些地址值（指针，或 "&变量"），再根据地址查看内存内容（适用于每次运行地址不固定的指

    针等）；

 6.在程序段中设置一个debug用的变量，运行后Watch是否改变（适合于不宜使用printf或其它打印语句或

    怀疑打印语句影响正常程序运行的地方）；

 7.用sizeof()检查类型长度、结构紧缩模式、拷贝长度等怀疑的问题；

 8.看PC（Program Counter）、堆栈情况；

 9.可能跟进汇编代码的地方也可尝试一下，可能可以找到一些线索，判断到一些原因；

 10.单步和连续运行交替使用，看现象是否不同，有些问题本身就有可能由单步引起的，比如中断ISR； 

 11.缩小泛围，先屏蔽其它功能；

 12.替代法找原因：A方法和B方法下现象不一样，基本可以断定原因就存在于A和B差异的实质上。

 

 如果常规debug不能解决，应暂时停下来，按逻辑整理出所有可能的原因

 不必蛮干，也不能太自信，列举的原因应包含所有的可能，特别要包括自己觉得绝对没有问题的原因！

 一般原因分下面几大类：

 1.逻辑错误：不符合标准和协议、不符合设计、不符合硬件手册规定；老老实实地死扣标准、手册吧，

   查一遍，再查一遍！从长远看，我们得不断积累领域知识和经验。

 2.编程错误：这是一个大类，难以细述，需要长期的素养，简单的原则是编程越规矩越好！从长远看，

   我们必须积累和养成软件框架、风格方面的“哲学”。

 3.移植问题：(a)硬件移植：在不同的目标机硬件上不同的内存、I/O寻址方式、不同的字节序

  （Big/Little Endian）、不同的访问时字节对齐方式等；(b)编译器：不同的编译器对相同的C代码会产

  生不同的目标码：例如struct的紧凑模式、int类型的长度等；(c)操作系统：不同OS的中断组织方式、

  系统调用方式等均不一样。该类问题容易疏忽，时时注意！

 4.其它软件模块的错误对你的模块的影响：不能急于怀疑。但是及时沟通应当值得鼓励。

 5.调试环境问题：你的程序没有问题，可能是你调试环境设置有问题，或者调试环境显示给你的只是一个

   假象！不过不要轻易怀疑这一点，否则有陷入消极强调客观原因黑洞的危险！

 6.硬件有问题：万不得已，也不能轻易怀疑，否则同样的黑洞也让人丧失斗志。

 7.编译器问题

 

给所有可能的原因排出优先级，按优先级顺序逐一排除

原则是最易于验证操作和排除的原因列最前面，这样我们一旦解决，可以省却很多工时和精力。

 

经过严密逻辑的地毯式搜索和轰炸还是不行，可以适量开展一些发散的猜想式的试凑法

可以假设一些逻辑上似乎不相干的原因，试一试。不过此法是违背方法论的，因此只能最后才用，而且只能用适量时间，不可恋战！否则容易陷入漫无边际的无序的泥沼。如果运气好，问题现象消除了，那么迅速返回到逻辑，把真正的原因和实质挖出来，否则，只是表面掩盖，隐患还是存在的。

 

如果仍然不能解决，马上申请组织技术攻关会

请调试者自己事先准备好全面、有条理的调试记录，准备讲解，不可支离破碎。

在产品开发过程中，我们每个开发人员调试程序 方法的科学性、有组织性直接影响到工作效率和进度。抓紧和利用一切时间是一方面，而得当的调试思维方式和调试方法尤其显得重要。

 

好的调试思路和步骤，如同抽丝剥茧，层层推进，富有实效，事半功倍；而在条理逻辑不甚清楚的调试思路下，如同没有目标的轰炸，抓不住问题的实质，可能使问题成为顽疾，久攻不下，事倍功半，身心疲惫，疲劳的开发人员伤不起啊。因此，有时碰到比较疑难的问题，首先不能乱，不能急躁，不要紧张，要保持清醒的条理和逻辑。有时不妨脱离计算机，借助一张白纸、一支笔思考一下，仔细分析一下所有的原因，然后逐一排除之。

 

 以下是我建议的步骤，大家感兴趣的话可以参考：

 

 必须精确地记录现象及其发生的环境

 最好用一个记事本，对大脑的自信永远比不过烂笔头嘛。

 

 先做完常规意义的debug

 debug可以有很多灵活的技巧：

 1.最基本的单步和断点；

 2.Watch变量；

 3.看内存；

 4.打印语句或打印变量值；

 5.打印出某些地址值（指针，或 "&变量"），再根据地址查看内存内容（适用于每次运行地址不固定的指

    针等）；

 6.在程序段中设置一个debug用的变量，运行后Watch是否改变（适合于不宜使用printf或其它打印语句或

    怀疑打印语句影响正常程序运行的地方）；

 7.用sizeof()检查类型长度、结构紧缩模式、拷贝长度等怀疑的问题；

 8.看PC（Program Counter）、堆栈情况；

 9.可能跟进汇编代码的地方也可尝试一下，可能可以找到一些线索，判断到一些原因；

 10.单步和连续运行交替使用，看现象是否不同，有些问题本身就有可能由单步引起的，比如中断ISR； 

 11.缩小泛围，先屏蔽其它功能；

 12.替代法找原因：A方法和B方法下现象不一样，基本可以断定原因就存在于A和B差异的实质上。

 

 如果常规debug不能解决，应暂时停下来，按逻辑整理出所有可能的原因

 不必蛮干，也不能太自信，列举的原因应包含所有的可能，特别要包括自己觉得绝对没有问题的原因！

 一般原因分下面几大类：

 1.逻辑错误：不符合标准和协议、不符合设计、不符合硬件手册规定；老老实实地死扣标准、手册吧，

   查一遍，再查一遍！从长远看，我们得不断积累领域知识和经验。

 2.编程错误：这是一个大类，难以细述，需要长期的素养，简单的原则是编程越规矩越好！从长远看，

   我们必须积累和养成软件框架、风格方面的“哲学”。

 3.移植问题：(a)硬件移植：在不同的目标机硬件上不同的内存、I/O寻址方式、不同的字节序

  （Big/Little Endian）、不同的访问时字节对齐方式等；(b)编译器：不同的编译器对相同的C代码会产

  生不同的目标码：例如struct的紧凑模式、int类型的长度等；(c)操作系统：不同OS的中断组织方式、

  系统调用方式等均不一样。该类问题容易疏忽，时时注意！

 4.其它软件模块的错误对你的模块的影响：不能急于怀疑。但是及时沟通应当值得鼓励。

 5.调试环境问题：你的程序没有问题，可能是你调试环境设置有问题，或者调试环境显示给你的只是一个

   假象！不过不要轻易怀疑这一点，否则有陷入消极强调客观原因黑洞的危险！

 6.硬件有问题：万不得已，也不能轻易怀疑，否则同样的黑洞也让人丧失斗志。

 7.编译器问题

 

给所有可能的原因排出优先级，按优先级顺序逐一排除

原则是最易于验证操作和排除的原因列最前面，这样我们一旦解决，可以省却很多工时和精力。

 

经过严密逻辑的地毯式搜索和轰炸还是不行，可以适量开展一些发散的猜想式的试凑法

可以假设一些逻辑上似乎不相干的原因，试一试。不过此法是违背方法论的，因此只能最后才用，而且只能用适量时间，不可恋战！否则容易陷入漫无边际的无序的泥沼。如果运气好，问题现象消除了，那么迅速返回到逻辑，把真正的原因和实质挖出来，否则，只是表面掩盖，隐患还是存在的。

 

如果仍然不能解决，马上申请组织技术攻关会

请调试者自己事先准备好全面、有条理的调试记录，准备讲解，不可支离破碎。