Bug实际不一定出现在看起来出现的地方
Bug实际不一定出现在看起来出现的地方
write by 九天雁翎(JTianLing) -- www.jtianling.com
作为初学者,一般都是看到Bug在哪发生的就只看到哪的代码,然后反复的想为什么会出,加日志吗,在Bug出现的前后两句加上日志,然后苦苦分析而得不出原因。当一个断言出现的时候更加是这种方法最派上用场的时候,因为Bug出在哪一行更明显了啊。
事实上,Bug却常常是因为其他原因引起的。最近的一个情况就是,文件打包工具在打包游戏数据时,总是有一个目录不能打进包中。我首先的方式是在Bug前后两句加上了日志,发现递归遍历文件和目录的时候并没有遍历到漏掉的那个目录。我是百思不得其解啊,不就是CFind的使用吗?MFC的东西不至于出现这样的错误吧?然后此问题在我的机器上又没有办法重现,所以我没有办法实际的调试代码。假如还是靠这样的思路几乎没有办法发现Bug了。
最后我回过头去,将日志添加了几个作用域,发现外面的遍历是正确的,再反过来看代码,发现原来是打包工具在定制哪个文件是确定打到那个包中时用的是平面结构,而测试组总监打包的时候用的是老的脚本,新的游戏数据添加了一个目录,打包工具的脚本中并不存在,在打包工具脚本遍历那一层就已经将那个目录丢掉了,所以里层的循环自然没有此目录,但是外层却能发现。。。这就是问题所在,假如我能早一点回过头去一层一层的看循环的条件,那么我可能很快就发现Bug了。。。。这也算是我不成熟的一个地方。虽然此例中有打包工具不是我做的,不是太熟悉的原因,但是不属于自己需要改Bug的代码不就是新手经验不足水平不够最最劣质的理由吗?(参考前一篇)
另外,这里举另外的例子,以前做文件打包系统的时候老是打包到一半出现ESP错误。。。。。。狂折腾代码,到了晚上十点总监亲自出马,全取代码重编,问题解决。。。。。。原来是编写工具的兄弟没有完全同步文件打包系统的库,头文件和lib不统一导致的问题。现在我是有经验了,碰到类似的问题,第一反应就是库没有统一。
还有一个例子,也是文件打包系统的问题,当时公司的游戏新加了声音,出现的问题是一旦声音打到我的包中,游戏运行会出现各种各样的错误,地图加载失败啊啥的,将声音从包中剥离出来,一点问题都没有。刚开始总监和我都怀疑是文件打包系统在频繁小批量读取时出现Bug,结果不是,然后只好跟代码,发现Bug时出时不出,这时总监和我的反应又都是哪个地方内存出现越界,导致这样莫名其妙的问题。但是最后狂看代码,折腾到十一点,突然总监一拍脑袋,不是吧,你的文件系统支不支持多线程啊?然后翻了翻声音系统的文档,明确说明,读取数据时需要线程安全。我彻底崩溃。。。。由于那个是我工作以来的第二个任务,我只需要关注,水平也就只够光注自己的的工作,根本就不知道声音那边是独立线程的。。。。一般而言,我们客户端是单线程的。。。。没有明确的要求,我怎么可能将文件系统做成线程安全啊?。。。。
第二天将文件系统做成线程安全以后。。。问题解决。。。这属于我最最刻骨铭心的Debug经历之一,还是那句话:Bug实际不一定出现在看起来出现的地方。---题外话:由于文件系统中为了统计数据等多种功能,太多函数带有状态和使用了类成员(特别是list),所以改成线程安全后效率惨不忍睹,而又没有办法将声音的线程取消,至今我们公司的游戏,声音还是没有打入我写的文件打包格式中,独立于打包系统之外。。。。。
write by 九天雁翎(JTianLing) -- www.jtianling.com
Posted By 九天雁翎 at 九天雁翎的博客 on 2009年03月27日