一个程序员的心路历程
一般我们的系统在上线的初期都采用DEBUG版本，因为初期系统存在着很多潜在的问题，一旦暴露，DEBUG版本也便于我们进行问题查找。
昨天吉林割接测试过程中发现一个问题，我们的系统在处理一条内容为空的手机上行短信时系统dump core了。经过调试发现是一处assert导致的，这处的代码断言上行短信的内容不该为空, 即assert(消息内容长度 > 0)。
正常来说我们系统接收到的手机上行的短信内容都应该不为空的，以前的定势的思维也让我在这块无端放了一个assert语句，反倒画蛇添足了。其实想一想，用户一不小心发了一条空短信也是完全可能的，起码我就发过不止一次^_^。但是空短信导致系统进程出异常这是万万不应该的，虽说DEBUG版本也是导致这一问题的一个原因，但是我们在检查输入参数范围时的不细心终归是最大的问题所在。
以后注意!^_^
河南项目实施，一波刚平一波又起呀！
前天凌晨，河南又割入很多家SP，昨天早晨上班通过日志发现程序的一个子模块进程隔一段时间重启若干次，通常是每一批数据推过来，就有一次重启的过程，日志中没有打印出出错的标志，进程莫名奇妙的就宕掉了，查看程序环境也没有发现CORE文件或者.assert文件，在代码关键的退出区域加入打印日志，重启系统后仍然有同样的问题。郁闷呀，没办法，在家里搭建测试环境，模拟测试，测试人员果然发现问题了，我定睛瞧看，哇，原来如此，测试的那个哥们是在前台启动的系统，这样shell输出的信息也能看得到，也就是说在后台日志文件中看不到的，在前台都看得到，那个模块之所以重启的原因是因为没有找到dso中的函数符号，换句话说就是我们在编译dso时忘记了链接某个.o文件了。这个功能是年初后加入到系统中的，真想不起来当时是如何测试的了，居然这样的问题都没有发现。打开Makefile查看，的确链接串中并没有该.o文件。修改后，重新编译，替换dso，重启程序，一切正常了。事后一想以前没有暴露出该问题是因为以前的消息处理流程没有走到这个分支，由于第二次割接导致出现新类型的消息，走到了该分支，问题因此暴露。
第二个问题也是疏忽所致。C里面最容易犯的就是忘记释放内存或者文件句柄之类的问题，这次让我遇到了。系统每天凌晨要生成一个清单文件，然后将该清单文件转移到指定目录下待被取走。程序在凌晨的时候的确准时生成了一份清单文件，但是用vi打开这份清单文件，vi提示最后一行不全，这才发现原来这个文件还没有写完，就被中断了。一位老同事马上用他的经验判断文件没有close就被移走或者改名了，这样系统缓存中的数据还没来得急写入文件就丢了，现象的确也是如此。查看代码，果不其然，唉这种低级错误都犯了。
切记：远离疏忽大意，说起来容易做起来难呀。
这里是
Tony Bai的个人Blog，欢迎访问、订阅和留言！
订阅Feed请点击上面图片。
如果您觉得这里的文章对您有帮助，请扫描上方二维码进行捐赠 ，加油后的Tony Bai将会为您呈现更多精彩的文章，谢谢！
如果您希望通过微信捐赠，请用微信客户端扫描下方赞赏码：
如果您希望通过比特币或以太币捐赠，可以扫描下方二维码：
比特币：
以太币：
如果您喜欢通过微信浏览本站内容，可以扫描下方二维码，订阅本站官方微信订阅号“iamtonybai”；点击二维码，可直达本人官方微博主页^_^：
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机，即可获得10美元现金充值，可 免费使用两个月哟！
著名主机提供商Linode 10$优惠码：linode10，在
这里注册即可免费获 得。阿里云推荐码：
1WFZ0V，
立享9折！
评论