一次因量子力学而 Debug 的痛苦经历

伯乐在线导读:调试 Bug不每个程序员工作中必须品。在 Quora 上有一个和 Bug 相关的热门问答帖:《What’s the hardest bug you’ve debugged? | 你调试过的最难 Bug 是?》。在众多回复中,Dave Baggett 的经历最让人惊叹,得到了 5500 多个顶。


回想起这个bug,仍然让我有些痛苦。作为一个程序员,在发现bug时,你学会了首先在自己代码中找问题,或许在测试一万次之后,你会把问题归咎于编译器。只有在这所有的都不起作用之后,你才会把问题归咎于硬件。

这是我遭遇一个硬件bug的故事。

抛开别的不说,我曾为《Crash Bandicoot》写存储卡(读写)代码。对于一个自大的游戏程序员,这就像是在公园里散步一样轻松愉快,我认为只要几天就写完了,最终调试用了六个礼拜。在此期间我做一些其他的事情,但我一直回来处理这个bug——几天内每天几个小时。这个bug实在烦人。

这个bug的症状是,当你需要保存你的进度时,代码会访问存储卡,而大部分情况下没有什么问题…但是偶尔读写会超时…没有任何明显的原因。一个短小的写入经常毁掉存储卡。玩家要保存进度,我们不仅不保存,还擦除他们存储卡上的全部东西。天哪。

过了一段时间,我们在Sony的制作人Connie Booth慌了。我们显然不能带着这个bug发布游戏,而六个星期之后我对于问题出在哪一点线索都没有。通过Connie我们向其他 PS1 开发者求助:有没有人出现过像我们这样的情况?没有。绝对没有任何人在存储卡系统上出现任何问题。

在你绞尽脑汁之后,你能做的唯一一个调试方法就是分而治之:一点点去除程序中的代码,直到留下的代码很少但你仍然出问题。像木雕一样去除没有问题的代码,留下的就是你的bug所在。

在这样的背景下挑战在于,视频游戏是很难去除某一部分的。在你删除模拟重力或者显示字符的代码后,如何运行游戏?

你必须做的是用一个假装做真正的事情,但实际上只是做很简单的不会出现bug事情的东西来替换掉整个模块。你必须写新的支撑代码来让这些玩意正常工作。这是一个缓慢而痛苦的过程。

长话短说:我做完了。我移除了大片大片的代码,相当多,只留下了初始化代码——就是准备游戏运行系统,初始化底层硬件等等。当然,我不能显示加载/保存菜单,因为我截除了所有的图像代码。但是我能够假装用户使用(不可见的)加载/保存屏幕并且请求保存,然后写入卡中。

我最终以一个带有这个bug的很少量的代码结束——但问题仍然随机出现!在大多数情况下没啥问题,但是偶尔会失效。基本上所有的Crash的实际代码都被移除了,但还是这样。这实在是莫名其妙:留下来的代码基本上都没做什么事。

在那时——估计是凌晨3点——一个想法蹦了出来。读写(I/O)涉及精确定时。无论是硬盘、存储卡、蓝牙发送器——随便啥——做读写的底层代码都是根据时钟来的。

时钟让不直接连接到CPU的硬件设备和cpu运行的代码同步。时钟决定了波特率——数据从一头传到另一头的速率。如果计时有什么问题,硬件或者软件或者两者都会乱七八糟的。这真的,真的很糟糕,并且通常导致数据损坏。

如果我们的初始化代码以某种方式弄乱了计时会怎么样?我又看了一遍测试程序中和计时有关的代码,并注意到我们将PS1上的可编程计时器设置到了1kHz(1000跳每秒)。这是比较快了,当PS1启动的时候,默认状态大概是100Hz。因此,大多数游戏将他们的计时器设置为100Hz。

这个游戏的带头(和除我外的唯一)开发者Andy,将计时器设置为1kHz,使得Crash的动作计算更加准确。Andy喜欢矫枉过正,如果我们要模拟重力,我们应该尽可能的提高精度!

然而如果提高计时器频率莫名其妙的干扰了整个程序的计时,故而将这个计时器设置到存储卡的波特率上会怎样呢?

我将计时器代码注释掉。然后我就无法复原这个bug了。但是这并不表示bug被修复了,这个问题是随机发生的。万一我只是运气好呢?

几天过去了,我还是在玩我的测试程序。Bug没有再出现。我回到全部的Crash代码中,修改了加载/保存代码,在访问存储卡之前将可编程计时器重置为默认设置(100Hz),之后设置回1kHz。从此之后没有发现问题再次出现。

但是…为什么?

我重新回到测试程序上,试着检测当计时器设置为1kHz时出现的那些错误的模式。终于,我注意到这些错误出现在使用PS1手柄的人身上。因为我自己很少这样做,所以我没有注意到(为啥我要在测试加载/保存代码的时候用手柄)。但是有一天我们的美工等我去完成测试(我确定那时候我在爆粗口),而他紧张的摆弄着手柄。卡损坏了。“等下,怎么回事?喂,再来一次!”

一旦我发现了这两件事是联系着的,就很容易重现bug:开始写入存储卡,动一下手柄,存储卡损坏。在我看来完全是硬件bug。

我去找Connie告诉他我的发现。她转述给设计过PS1的硬件工程师。她被告知:“不可能,这不可能是硬件问题。”我跟她说问一下我能不能直接和他说。

那个工程师给我打电话了,他用着他的烂英语,我用着我更烂的日语,我们争论一会。我最后说:“我给你一个30行的测试程序,让你在动手柄的时候能够出现这问题。”他答应了。他向我保证,这是浪费时间,而他正在一个新项目上很忙,但因为我们是Sony很重要的开发者,他会试的。

第二天晚上(我们在洛杉矶,而他在东京,所以对于我来说是晚上而他是到了第二天),他给我打电话,不好意思的向我道歉。这是个硬件问题。

我还是没有完全搞清楚问题到底在哪,但是我的印象中,从Sony总部的反馈听到的是,如果将可编程计时器设置到足够高的时钟频率,会影响到主板上时钟晶振附近的一些东西。这些东西之一就是存储卡的波特率控制器,同时也设置手柄的波特率。我不是搞硬件的,所以对于细节我相当模糊。

但是主旨是主板上两个独立部分的串扰,以及手柄接口和存储卡接口数据发送的结合在 1kHz 的时钟频率下会导致丢位,从而数据丢失,以致卡损坏。

这是我全部编程生涯中,唯一一次因为量子力学而debug的问题。

5 6 收藏 16 评论

关于作者:熊铎

野生业余程序员搞搞Android 玩玩前端 仅此而已 个人主页 · 我的文章 · 19 ·     

相关文章

可能感兴趣的话题



直接登录
最新评论
  • Claude Zhao   2013/11/07

    "这是我全部编程生涯中,唯一一次因为量子力学debug的问题"

    哈哈

  • 调试这种BUG是很让人崩溃的一件事情...
    我曾经因为360安全卫士导致过一个BUG...当时调试了三天临近崩溃...

  • Yan   2013/11/08

    做视频采集卡开发的时候也因为多路的始终频率问题而头疼,很难说我们遇到的问题是硬件Bug。最让人头疼的是,硬件工作的不对了,而软件开发人员不能知道是硬件坏了,还是自己做错了

  • Norz   2013/11/08

    。。。这个bug确实是。。。蛋疼

  • 黄利民 站长 2013/11/08

    转摘微博上的一些评论:

    @那厮达克:曾经有一个bug让我差点崩溃,无线收发器会停止工作,随机发生,怀疑是内存泄漏引起,把所有代码删得差不多,一个多月后仍然搞不定,最后原始到对着芯片手册查寄存器,发现TI官方提供的头文件里有一个寄存器的地址错了,造成缓冲区清空出错。解完这个bug就和@vcveyy 高高兴兴地领证去了……

    (原来@那厮达克 和@vcveyy 是这样去领证了…… [嘻嘻])

    @Erucy:C++函数参数大小超过64k(这个阈值具体记不清了),编译器在函数结束后退栈时只退了低16位地址,于是指针就跑飞了……

    @再龙再龙:我调试过的最难的bug是给OpenCV库做OpenCL目录的开发时,一个remap函数,我用GPU实现时,和CPU结果对比总是有问题,我一直在我的程序上找毛病,1个月后,我改变思路,发现是OpenCV库中本身的代码出了问题。。

    @糖醋鼻子:每一个诡异的BUG后面必然隐藏着一个极其2B的低级错误,且2B程度与BUG诡异程度呈正比

    • 黄利民 站长 2013/11/08

      再补充:

      @kami_桂木桂马:我碰到最坑爹的是內存頻率設置太高(文檔建議值)導致tftp的報文出錯,我一直以為是dma控制器的代碼問題,猛查。春節初五加班寫了一個crc校驗來規避問題,最後還是硬件人員測試了內存發現這個頻率下內存各類指標均超標,結果當時我就草了,當然還有更詭異的5.5m問題據說我離職了才解決

  • Edward Shen   2014/05/12

    我遇到的最坑爹的bug也是硬件bug。 计算机电源质量不好,显示器电源质量不好,显示器信号线质量也不好。 造成显示器模糊。 我告诉老板是硬件问题,他不信。非要我修改这个bug。
    很久以后,他自己测试了一遍,发现是硬件问题。

  • farewellwho   2014/05/17

    单步调试没问题、连续运行就出错的bug一定是世界上最让人头疼的了。。

    • 萧何   2014/05/27

      这可能是多线程的问题了,或许是程序使用了非安全的内存,那块儿内存还没有初始化好你就要用,调试时间更长

  • Yukino Hayakawa   2014/11/21

    为什么把end up翻译成终止

    • 黄利民 站长 2014/11/21

      谢谢反馈,已更新。 CC:@cugbabyebar

      PS: end up: reach or come to a certain place, state or action, esp by a lengthy route or process 到达或来到某处, 达到某状态或采取某行动(尤指经一长路程或过程):

  • ironlee 程序员 2015/05/29

    文章写得不错 我觉得每遇到大BUG都这么记录 多么美好啊!!!!

  • Dapper   2015/12/07

    我同学告诉我他一一百来行的c++程序过不了在线测评,莫名其妙运行时错误,在自己电脑上无法复现,换了win xp,win7,ubuntu desktop,换了四五只g++版本,无法复现,代码根本看不出错。最后去找来服务器,(ubuntu server)发现只有在服务器上编译并开启O2优化才报错,貌似是堆栈溢出,可这没道理啊,后来把我同学顺手加在递归函数前的inline删了就好了,非常不科学,不过懒得看汇编代码了,下次别作死就行

  • tianxun   2015/12/08

    好崩溃。。。。。。。。

  • 错看成 : 一次因量子力学而 Debug 的痛经经历

  • 果理 C++开发工程师 2016/09/21

    确实比较麻烦,在不确定是否是自己问题的时候查问题是做头疼的事情!

跳到底部
返回顶部