难忘的Bug调试经历

相信每位程序员都有过一段不堪回首地Bug调试经历，程序员一听到自己的程序有Bug，会有各种搞笑的反应，大家可以移步去看看“ 程序员遇到Bug后的30种常见反应 ”。
目前，的社区问答网站Quora上出现一个很火的讨论： What's the hardest bug you've debugged?很多程序员在下面留言，把自己痛苦或者难忘的Bug调试经历分享给大家，笔者就所讨论的内容，整理了两位程序员的回答。不知大家是否有过同样的经历。
Dave Baggett：代码、硬件 谁之过？
ITA Software联合创始人、ink***网站创始人Dave Baggett分享了自己痛苦的调试经历，在苦苦反复测试代码后，竟然发现是硬件惹的祸。
我为Crash Bandicoot写了内存卡（加载/保存）代码，我花了6周时间才停止对这段代码进行调试，在这段时间里我还做了些其它东西，但还是会过来调试这个Bug——可能是几个小时、几天。
在每次保存进程的时候，程序就会一直访问内存卡，并且进行正常工作。仅仅一个短暂的写入操作，常常会破坏内存卡。玩家会保存一些东西，而它不但不会去保存，反而还会去破坏内存卡。
显然，我们不能跳过这个Bug，即使6周后，我仍然也没发现任何线索。后来，我们通过Connie把内容放到了PS1开发者论坛上，看是否有人遇到过类似问题？答案是否定的。
当程序员无计可施的时候，能做的是对代码进行分而治之，不断地去排查错误，消灭错误，直到后剩下非常小的一块，再去慢慢研究问题所在，可不幸往往就这样，在排除了许多错误以后，该Bug还是会出现。
在这个过程中，我们所面临的挑战是如果把代码删除了，该如何让游戏继续运行下去？我们需要替换整个模块，并且模拟一些真实的东西，但实际上，这并未起到太大作用。你必须要编写新的架构代码来保持整个游戏的运行，这是慢且痛苦的过程。
我不停的移除越来越多的代码，直到只剩下启动代码——仅仅是启动这个系统并且初始化渲染硬件等。当然，这是肯定不会提供加载/保存菜单，因为我已经移除了所有的图形代码。不过我可以假设用户在使用（不可见）加载/保存操作，并且询问是否保存，后再写入卡上。
后，只剩下极少的代码在工作，但Bug仍然存在，大多数时候都可以正常工作，但每隔一段时间，它就会失败。几乎所有的Crash代码都被移除了，但仍然发生错误，太莫名其妙了，剩下的代码真的没有做任何事情。
此时，大概上午3点左右，一个念头在脑海一闪而过。读和写（I/O）操作需要定时。无论你是否在处理一个硬盘、闪存卡、蓝牙发射机——不管怎样，底层代码的读写操作必须要根据的时间点来执行。
时钟周期让硬件设备可以不直接连接到CPU——并且让代码运行与CPU保持同步。时钟决定Baud Rate——数据从一端发送到另一端的速率。如果时间混乱了，那么硬件或软件都有可能会有问题，这真的是太糟糕了，而且在通常情况下，还会导致数据损坏。
倘若我们编写的设置时间的代码混乱了，那么定时会发生怎样的情形呢？我再次查看了与时间相关的测试代码，注意到设置的可编程时间定时是PS1到1kHz（1000ticks/second），这是相当快速的，大多数游戏一般都是设置在100Hz这样。
随着时间的推移，我不停地测试程序，回到Crash代码块，并且修改加载/保存代码，在访问内存卡之前，把可编程时间定时调整到默认设置（100Hz），然后再将其调制1kHz，我们再也没看到读/写问题。
为什么，我反复地思考和测试，并且不停地调整时间。有一天，我突然细微地观察到了两个东西，并且很容易重现：开始写内存卡、操纵控制器、存储卡损坏。这看起来就是个硬件Bug。
后来，我找到曾经设计过PS1的硬件工程师Connie，并且把发现的问题告诉她，她回答：“不可能”，并且我们进行了争论，我想当场测试给她看，但是她觉得是在浪费时间，并且她为新项目忙地焦头烂额。第二天，她向我道歉，并且告诉我，的确是一个硬件Bug。
文章来源：unity3d 虚拟现实 http://bbs.9ri***/thread-144647-1-1.html