疏忽大意招致恼人'BUG'
河南项目实施，一波刚平一波又起呀！
前天凌晨，河南又割入很多家SP，昨天早晨上班通过日志发现程序的一个子模块进程隔一段时间重启若干次，通常是每一批数据推过来，就有一次重启的过程，日志中没有打印出出错的标志，进程莫名奇妙的就宕掉了，查看程序环境也没有发现CORE文件或者.assert文件，在代码关键的退出区域加入打印日志，重启系统后仍然有同样的问题。郁闷呀，没办法，在家里搭建测试环境，模拟测试，测试人员果然发现问题了，我定睛瞧看，哇，原来如此，测试的那个哥们是在前台启动的系统，这样shell输出的信息也能看得到，也就是说在后台日志文件中看不到的，在前台都看得到，那个模块之所以重启的原因是因为没有找到dso中的函数符号，换句话说就是我们在编译dso时忘记了链接某个.o文件了。这个功能是年初后加入到系统中的，真想不起来当时是如何测试的了，居然这样的问题都没有发现。打开Makefile查看，的确链接串中并没有该.o文件。修改后，重新编译，替换dso，重启程序，一切正常了。事后一想以前没有暴露出该问题是因为以前的消息处理流程没有走到这个分支，由于第二次割接导致出现新类型的消息，走到了该分支，问题因此暴露。
第二个问题也是疏忽所致。C里面最容易犯的就是忘记释放内存或者文件句柄之类的问题，这次让我遇到了。系统每天凌晨要生成一个清单文件，然后将该清单文件转移到指定目录下待被取走。程序在凌晨的时候的确准时生成了一份清单文件，但是用vi打开这份清单文件，vi提示最后一行不全，这才发现原来这个文件还没有写完，就被中断了。一位老同事马上用他的经验判断文件没有close就被移走或者改名了，这样系统缓存中的数据还没来得急写入文件就丢了，现象的确也是如此。查看代码，果不其然，唉这种低级错误都犯了。
切记：远离疏忽大意，说起来容易做起来难呀。
评论