昨天看了“外刊IT评论”上的一篇名为《软件编程21法则》的文章,文章中提到的一条法则是:“软件直到被变成产品运行至少6个月后,它最严重的问题才会被发现”,当时表示认同。不过仅仅相隔一天,这条法则就变成了眼前的现实。

今天上午我们的某版本系统在某省出现了故障,该版本在这个省上线恰好将近6个月^_^,系统上线以来一直运行良好,直到这次故障。故障现象为"挂死":所有进程都挂死在某一把锁的lock上。以前出现这种情况多为某个进程加锁后,在锁内异常退出,未能释放锁而导致其他进程挂死。这种"挂死"多是代码中访问非法内存地址导致的,一般都会有core文件dump出来。不过这次出现挂死后,我们并未找到core文件的影子。查看系统运行日志也无果。通过脚本将所有该应用的子进程的运行栈快照收集到一个文件中,然后对这个数据庞大的文件进行分析,以试图找到一些蛛丝马迹。

分析发现绝大多数子进程都挂起了,其运行栈栈顶多为:
lwp_mutex_timedlock (f1444c28, 0)

不过只有一个进程与众不同,它的栈顶是一个我们自己实现的函数,这里暂且称这个函数为foo_func吧。迅速查看foo_func的源码实现,发现一个while循环,第一时间想到:是不是foo_func进入while死循环了?在故障应用主机上用top查看一下系统运行状态,发现确有一个进程占用cpu很高,而且持续很高。pstack一下这个进程,栈顶端果真就是foo_func,“死循环”的推论是正确的。 即使这个进程死循环了,怎么会连累其他进程也停止工作了呢?原因就在于这个死循环是在这个子进程获得锁之后发生的,因为死循环了,导致无法释放这把锁,其他子进程干着急也无可奈何!

foo_func为何能进入死循环?仔细斟酌一下foo_func的代码也不难得出:代码中混用了int和unsigned char,导致数组下标值变为负数,数组访问溢出,读取到的值是随机值,所以死循环也是随机发生的(之前几个月运行都良好也是因为这个原因)。 C语言不是强类型的,int和unsigned char两个宽度不同的类型可以放在一起使用。C编译器帮你做隐式转换,转换规则虽不十分复杂(C99引入了rank概念后,转换规则略就显复杂了),但也很容易犯错,这也是我们常说的C陷阱之一。另外foo_func代码本身的功能逻辑也有漏洞,这里就不细说了。