条件断点引发的血案

今天在调试打条件断点时，想起一出调试往事。同样也是条件断点，难倒了我们这所有程序员。为了以后总能记得这事，把这事写到偶博客里。

 

当时我们服务器的光哥在Linux下用gdb调试一段代码，发现执行到一个地方时有一个变量的值是一个与预期不符的值，于是顺手打了一个条件断点：当执行到这一行，这个变量的值为那个有问题的值时就断下来，以确定是什么情况下出问题。

 

结果，问题就来了…

 

跑过几次后，光哥郁闷的发现，这个变量的值每次都会错，而且进一步调试后发现，每次都是在这个条件断点所在的行，变量的值就会突变成有问题的那个值。

反复研究得不出结论后，光哥终于不撑了，开始拉外援。看代码，查语法，查线程，看汇编，打数据变化断点。最后都怀疑到硬件上了，服务器都重启几次了…全部无果。一个又一个的程序在光哥的这段程序前倒下了。

 

最后，终于有人发现问题了，条件断点的条件语句写错了，本来条件应该写：

nTableID == 864

结果手一抖，写成了：

nTableID=864

这下好，每次执行到这个断点时，这个变量的值就直接被改写了，而且由于这个赋值语句的求值为非0，于是每次还都能断下来。关键最狠的是，条件断点时把变量值修改了，你针对这个变量地址打数据变更断点，是不会被触发的。

 

结论：永远不要把常量写在逻辑运算符右边。

 

写成下面的样子，绝对不会错：

864==nTableID

 

这一条，不光写代码时非常有用，在条件断点时也非常有用。这种问题从来都是一但出现，非常难查的（眼前放着=，你也不觉得有错的）。不要为所谓的美观、习惯而拒绝这个写法了，它真的能让你的程序生涯更愉快的。