〔9〕抽刀断手之前／新人向的debug参考 - c语言吧

level 4

九头一存楼主

一楼度娘。

2012年05月04日 15点05分 1

level 4

九头一存楼主

工具。假设提问者确实理解了自己的设计，不至于对主要算法、结构甚至使用的功能、设备和其他术语缺乏了解。（实际上的反面例子并不少见。我曾经被一个正编写某单片机定时器中断程序的提问者问及〔定时器是什么〕和〔TMOD是不是定时器〕。）
* 假如开发平台比较容易获得输出（比如有显示屏或是有通信功能），在怀疑有问题的部位给出测试输出。比如在某次变换产生结果之后，立刻输出相关信息——这可能是某个关键的变量值，某个分支的执行路径或是执行任务的进程／线程ID等等。这些输出可能会显示出异常现象发生的大体位置和直接原因。
* 一旦确定了大体位置，往往需要一种调试器以便直接观察相关的控制流和数据。设置一个在猜测位置附近的断点，配合适当的watch/单步跟踪观察涉及到的数据，藉此确认错误数据／控制流和期望的差异。（一种可能的情况是程序得到了
正确的
数据，但没能正确选择变换方式——比如拿到了某棵子树的根节点，却误认为拿到的是此根节点的某个子节点。至于数据错误的情况，请逐层追溯各变换算法的实现。）
* 如果在平台A上开发用于平台B的程序，挑选一种具有调试功能的仿真器或许能减少一些外围劳作，尽管仿真器不一定能模拟实际的输入（比如试图仿真某个模－数转换的输入量）。如果开发机和测试机可以通信，也请尽量利用，这时往往可以在能检测到真实输入的情况下进行一定程度的调试。
* 如果在开发独立环境下的程序，除了同样需要考虑仿真器之外，也许在出错时进行一次core dump会给出更直接的数据供解读。
* 对某些语言的初学者而言，一种典型的情况是发生了访存违例。实际上这种情况的具体位置确定可以直接参考调试器汇报的崩溃位置。内存泄漏也往往有方便的工具进行检测（比如valgrind）。
即使找出了错误的位置，也不一定能改正错误（比如某些竞态条件引发的内存错误）。不过至少作出了这些努力之后，提问者已经大体明确了自己的期望，并能对发生的问题和问题的相关细节作出有条理的描述——换言之，他现在提出的问题会更明确而有章法，获得解答的可能性也更大。
写到这里，突然发现实际上这坨东西绕了很大一个圈子仍然不得要领。
当提问者单单表达了他希望对一个含混的问题获得解答之愿望时，他缺乏的或许是知识和经验，但或许更多地是解决问题的欲望。缺乏知识和经验的入门者只是新手而已，不意味着他是一个缺乏在不熟悉的领域中试图搜集资料、分析问题和解决问题能力的〔小白〕，或者动辄faint的旁观者。
所以请不要旁观问题。提问者始终是问题的核心，无论他的发问对象是自己还是别人，无论最终成功解答了问题的人是自己还是别人。

2012年05月04日 15点05分 3