问你发现并修复过的最难的bug是什么？

EN

一个jpeg解析器，运行在监控摄像头上，每当公司的首席执行官走进房间时，它就会崩溃。

100%可重复错误。

我没有骗你！

这就是为什么：

对于不太了解JPEG压缩的你来说--图像被分解成一个小块的矩阵，然后用魔术等方法进行编码。

当首席执行官走进房间时，解析器卡住了，因为他总是穿着一件上面有方形图案的衬衫，这引发了一些特殊情况的对比度和块边界算法。

真正的经典。

这并没有发生在我身上，但是一个朋友告诉了我这件事。

他不得不调试一个很少崩溃的应用程序。它只会在9号之后的9月的周三失败。是的，一年中有362天是正常的，一年中有三天会立即崩溃。

它将日期格式设置为“2008年9月22日星期三”，但是缓冲区太短了一个字符--因此只有当您有一个2位数的DOM时，它才会导致问题，该DOM的日期的名称在月份中最长。

这需要了解一点Z-8000汇编程序，我将在我们进行的过程中解释。

我在一个嵌入式系统上工作(用Z-8000汇编程序)。该公司的另一个部门正在同一平台上构建一个不同的系统，并编写了一个函数库，我也在我的项目中使用了它。错误是，每次我调用一个函数时，程序就会崩溃。我检查了所有的输入；它们都很好。这肯定是库中的一个bug --除了这个库已经在全国数千个POS站点中使用过(并且运行良好)。

现在，Z-8000 CPU有16个16位寄存器，R0，R1，R2 ...R15，这些寄存器也可以寻址为8个32位寄存器，名为RR0，RR2，RR4..RR14等。该库是从头开始编写的，重构了一系列较旧的库。它非常干净，遵循严格的编程标准。在每个函数开始时，将在函数中使用的每个寄存器都被压入堆栈以保留其值。一切都很整洁--它们是完美的。

然而，我研究了这个库的汇编程序清单，我注意到这个函数有一些奇怪的地方-在函数开始时，它有PUSH RR0 / PUSH RR2，在结束时有POP RR2 / POP R0。现在，如果你没有遵循它，它在开始时将4个值推送到堆栈上，但在结束时只删除了其中的3个。这就是灾难的秘诀。堆栈顶部需要返回地址的位置有一个未知值。这个函数不可能工作。

除了，我要提醒你，它是有效的。它每天在数千台机器上被调用数千次。它不可能不工作。

经过一段时间的调试(这在使用20世纪80年代中期的工具的嵌入式系统上的汇编程序中并不容易)，它总是会在返回时崩溃，因为错误的值是将它发送到一个随机地址。显然，我必须调试工作的应用程序，以找出为什么它没有失败。

记住，这个库在保存寄存器中的值方面做得非常好，所以一旦你将一个值放入寄存器中，它就会留在那里。R1中有0000个。当该函数被调用时，它总是有0000。因此，该bug在堆栈上留下了0000。因此，当函数返回时，它将跳转到地址0000，这恰好是一个RET，它将从堆栈中弹出下一个值(正确的返回地址)，并跳转到该地址。这些数据完美地掩盖了这个错误。

当然，在我的应用程序中，我在R1中有一个不同的值，所以它就崩溃了……