Bug

上周三晚，河南’前线’反馈，河南移动手机用户投诉，经查是话单丢失。查看后的确有蹊跷，按照数据库中录入的原始话单数据来看，这几条记录的确是该生成话单的。之后又有同事发现出现丢话单的问题不仅仅这几条，而是一批一批的。没什么头绪，一夜无话，周四发现每天入库的可生成话单记录数居然比话单多出100万，也就是说我的程序居然少生成了100万话单，按照一条记录1角钱，这也是10万块呀，事情紧迫，问题查找的历程开始。 ...

最近自己曾经辛苦耕耘过的两个项目同时上线，相关问题也就逐渐暴露出来。工作这两年多时间以后，使我有这样感觉：’测试永远都是不完备的’，有些问题只能在商用过程中发现，呵呵，明确一点啊我不是搞测试的:) ...

记得刚到公司做第一个项目时，mentor要和我一起看看我刚实现完的一些代码，当时有些不解，难道是不相信我写的代码么？最后事实证明：我的代码中有很多缺陷，有的还是很严重的缺陷。后来知道这个过程叫’代码评审’，是保证软件质量的一种手段，而且是很重要的一种手段。代码评审的形式有多种，最正式的一种就是召集公司或者部门的一些’大牛’们，围坐在会议室中，一行一行的审查你的代码；简单的形式就像我和mentor做的那种，一个编写代码的人和一个对系统特别了解的人在一起评审，效果不见得不如正式的评审，起码我是这么认为的。 ...

就在昨天，就在我们的项目要结项的时候，一个影响力不亚于’广岛原子弹’的bug出炉了，蒙蔽我近一个月的问题终于被澄清了，不过为时已晚，项目即将上线，如果想彻底地解决这个问题，需要对整个系统的实现架构作调整，目前能做的只是’亡羊补牢’了。 ...

内存问题是C程序员永久的话题，也是最能让C程序员心痛的话题。内存bug即隐秘，危害又大，而且往往当你解决了它之后，你会发现你的错误是多么的低级。以我为例，看下面的两个case: CASE1 背景: 配置信息读取 Bug现象: 通过打印语句观察到，在配置读取中间时刻，某一指针突然被置为NULL，出core。 耗时: 6小时 问题所在及分析: 经过6小时的不懈努力，终于发现了这一让我哭笑不得的低级错误。问题原因大致是这样的： 我定义了一个存储配置信息的结构体变量指针，并在初始化的时候给该指针在共享内存中分配空间，下面的代码就是我分配空间时的代码 xx_t *p; …// ...