debug笔记&检讨

昨天测试部门的人报告过来一个Severity是Critical的错误——某人负责的某个component经常出现随机的core dump，概率大概是0.3－0.4。把出问题的版本弄到板子上试了一下，我手气还真好，头一次就重现了，:(

虽然我是喜欢C语言，但是这东西的内存错误的确太让人头疼了，解决起来那叫一个狗咬刺猬——它没处下嘴呀。好在还有一个core文件，gdb打开一看，segmentation fault，最强的是出问题的位置——pthread_cancel()。

坦白地说，看到这个结果的时候我并不是很吃惊。原因在于，自己当时写这段code都拿不准，以一个不合法的pthread_t类型的值（比如一个已经结束 的线程的id）为参数调用pthread_cancel()会发生什么事情。应该说我不是一点都不负责的人，当时查过的，man page上说pthread_cancel()收到一个非法参数，不会产生恶劣后果，返回一个错误代码而已。

可是铁证如山，程序已经崩溃了。先把对pthread_cancel()的调用删除试试看，问题消失。没有别的办法，google一下吧： “pthread_cancel segmentation fault”，打开的第二个搜索结果就明说了，Linux的Native POSIX Thread Library的实现，有一个race condition，表现出来的现象是，对一个正要结束的线程调用pthread_cancel()的时候，会随机的收到SIGSEGV。这个问题在 UNIX各个版本，如Solaris，HP-UX，AIX上面都没有。

后果：当天晚上工作到9点50，今天又花了半天时间修正和测试解决方案，用pthread_mutex和pthread_cond系列函数改正了线程间同 步的机制。新方案不单避免了Linux NPTL中的这个race condition，而且把程序本身的性能提高了，响应速度比那个有漏洞的版本还快了很多。

三点需要检讨：

第一，   觉得“可能有问题”的时候，事情一定会向着最坏的方向发展，问题一定会发生，所以不能放过任何一点担心或者疑惑；

第二，   事实证明不是能力不够，明明能做到很好，而因为侥幸心理和懈怠情绪作怪，才出了大问题，所以工作中要更加认真负责；

第三，   测试不能满足于一次两次测试通过，要多测几次，以免测试次数太少时，没有发现小概率随机出现的问题。