Debugging

WinDbg有一个挺有意思的功能，叫做”Trace and Watch Data” — “wt”命令。WinDbg的help文件解释道:

The wt command runs through the whole function and then displays statistics, when you execute this command at the beginning of a function call.

也就是, 当你在debugging的时候，你step到一个function的开头（比如通过break point停在一个function开头），这时候你想获得关于这个function执行时候的详细信息，就在command窗口，输入wt，这时候debugger就会替你执行整个function到它return的地方，并提供给你这次执行的详细信息。比如下图，就是我用WinDbg attach到一个正在执行的notepad后，某次执行”wt”时得到的结果:

可以看到，这个function执行的详细信息被显示出来。比如function在stack的call depth，以及每个被call的function的执行的指令数目, 被执行的system call等等。这个是动态执行的trace，是根据当时的具体输入来的，所以不会cover所有code。另外，因为inline function在这里不被显示为一个function call，所以你还可以知道那些function被编译器inline了，那些没有。

感觉这是一条很有用也很强大的命令，在performance tuning的时候能提供很多有用的信息。我这里描述的是最简单也是最常用的用法。更具体的用法，请查阅WinDbg的帮助文件。

今天参加了一个Debugging的培训。其中有一段说到一个重要的Debug的手段叫做”Bug Talk”。大概意思就是，你坐在屏幕前调一个Bug已经好几个小时了，还是毫无头绪。这个时候，你要做的就是冲进一个同事的办公室说:”我要Bug Talk”，同事于是心不在焉的听你描述你的Bug，说着说着你就突然有思路了（虽然同事可能啥也没说）。然后，你回到电脑前，很快就有了进展。这就是”Bug Talk”。其中含义调过程序的都应该明白。

培训员又讲了一个相关的趣事。据说Stanford有门CS的编程课，有很多lab session，让大家动手。虽然有TA负责解疑，但是老师规定，所有有问题的人必须先到实验室的墙角的一个玩具熊面前描述自己的问题，如果还是不行，才能找TA。据说就这样，绝大部分人最后都不需要TA的帮助就能独立搞定程序。有个毕业生很多年后参加一个Party，大家说起这个趣事。她老婆再旁边突然恍然大悟得说：我一直不明白为什么他每次遇到难题，都会一个人跑到墙角自言自语一番。这下终于明白了。

当张嘴用语言描述你的问题的时候，往往能够理清思路，从毫无头绪中看出解决问题的脉络。