您曾经调试过的最困难的bug是什么？本文将介绍作者至今最困难的一次调试经历，希望从他怀疑硬件，再到怀疑软件到最终解决问题的过程中，能够为读者带来一些启示。

当我采访开发人员时，有时会问这样一个问题:“您曾经调试过的最困难的bug是什么?”大多数人都喜欢抛出一段特殊的缺失分号的血泪史，一个难以使用的API，或者他们抓狂地修改旧的、无文档的代码经历。以下是我对这个问题的回答。

问题

问题来自一台有多个条形码读取器的机器。我们已经制造了8台这样的机器，其中一台在英国生产了几个月，而其余7台刚刚在中国安装完毕，而问题就出在了中国的其中一台机器上。

我们收到一份报告说其中一台机器投入生产后不久就停止了工作。客户说有一个他们无法解除的错误。这个错误会中止产品生产，每停机一分钟就会造成很大的经济损失。在任何时期，我们都不希望出现这种情况。我进行了远程操作，发现摄像头已经停止向PLC(可编程逻辑控制器)发送结果，导致我们的软件用户界面发出警报。在这台机器上，将ID40作为数字IO予以连接以直接向PLC输出通过或失败的信号。这表明，故障可能与软件无关，但在这个行业摸爬滚打过几年的我知道：硬件和PLC通常都很稳定，95%的情况下是软件出了问题，所以我总是假设是软件出了问题。

从字面上看，这个故障意味着PLC认为触发了摄像头，在它再次触发摄像头之前没有收到数字IO结果，要么摄像头没有被PLC触发，要么摄像头没有输出通过或失败信号，要么PLC没有接收到通过或失败信号。我以为这是一次偶然，但如果是这种情况，重置和恢复就可以解决，而客户反映说，这么做没用。这台机器将继续生产下一个产品，然后再次停止。在远程观察到这一点后，我告诉他们重新启动这台机器。我对此没有合理的解释，希望这只是一次偶然(从来就没有偶然)。几个小时后，我又接到了电话，还是同一个问题。这一次，客户已经禁用了导致问题的摄像头，但是现在，第二个(托管的)摄像头显示出相同的错误。

调试第一天

就这一点，我的想法是：

相同的软件在英国已经运行了几个月，尽管在机器上略有不同。
这通常是一个摄像头的配置问题，但如果是这种情况，问题将出现在第一个产品，而不是运行了一个小时左右之后。
这发生在这台机器的所有摄像头上，所以它不是一个硬件故障。

经过办公室内的一番讨论之后，我们指示客户工程师启动摄像头。这不是让客户做的最简单的事情，尤其是在生产中。这些设备没有开关按钮，所以必须拧开一个项圈，断开电缆，然后重新连接，这似乎解决了问题，坚持了两个半小时。

有一个临时的解决方案，就是从车间中获取一个尚未发货的控制单元，并将其转移到办公室，然后我们部署它，假设它是一台出现问题的机器，连接摄像头并侵入脉冲发生器，模拟来自产品的物理机器的数字输入，这一切大约需要一天的时间。在这段时间里，我们发现这个问题几乎每两个半小时就会重复发生一次。与此同时，部署在中国的所有其他机器都在正常运行，一天24小时没有任何问题。

调试第二到四天

我们成功解决了这个问题，摄像头似乎锁定了。当脉冲发生器向它发送一个触发时，灯是固态的，触发灯不会亮。在这一点上，我非常确信这不是一个软件问题。我们请求Microscan提供技术支持，但仍在办公室进行测试。在接下来的几天，我们发现这个问题几乎每4.5千次触发出现一次，这就解释了为什么中国客户每两个半小时就会重复看到这个问题。我们还发现，只有当摄像头以一定速度触发时，才会发生这种情况。这解释了为什么这个问题只出现在9台机器中的1台上。

调试第五天

办公室里有很多关于PLC或摄像头的争论。双方都不能用任何理论来解释，相关主管建议将摄像头的网线从机器上断开。我们利用Telnet在批处理开始时使用以太网连接设置摄像头，发送摄像头正在读取的条形码中寻找的匹配字符串，使用以太网连接来获取摄像头看到的图像以及通过或失败的结果，这是通过Web请求完成的，直接输出到PLC的独立数字IO结果。在生产环境中，没有以太网连接不是一个可行的解决方案，因为用户需要查看图像，这让软件变得无用，因为就我们而言，这样就不进行产品检查了。然而，我们试了一下，效果不错，这个摄像头整夜都在运转，没再锁定。

调试第六天

我们重复测试多次，先连接以太网，然后断开，结果是可重现的，所以认为这肯定是一个软件问题。第一个理论是图像请求的每次触发都会导致问题，因此我们修改代码以删除该功能并将其部署到测试机器上。但这个问题仍然存在。这时，我们被难住了。以下是我们掌握的信息：

如果以太网连接在运行开始后断开(因此允许发送匹配字符串)，则摄像头可以正常工作
在大约4500个产品（误差有100个左右）之后，保持以太网连接会导致摄像头锁定。

这毫无逻辑可言。在我们发送了匹配字符串，并删除请求图像的代码之后，我们没对连接做任何事情。

调试第七天

我在机器上安装了Wireshark。我不知道为什么会这么做，大概只是一个猜测。我们仍然有图像请求的删除，所以我希望看到通过Telnet的一些摄像头的最初设置，然后什么也没有。我实际上看到的是通过Telnet从摄像头向我们发送的数据流。检查数据很明显，它通过我们打开的Telnet连接向我们发送匹配结果来配置摄像头设置。

这种行为在我们能找到的任何地方都没有记录，当然我们也没有刻意要求这么做。我们甚至没有监听响应。

我们研究了如何与摄像头通信。我们在第一次需要的时候就打开了一个TCP连接，并让它通过应用程序更改摄像头设置。我们对此进行了修改，以便在发送完所需信息后关闭连接，如果需要则重新打开连接。在接下来的几天，我们对它进行了彻底测试。

结论

我还是不明白这是怎么把摄像头锁定的。我们通过Telnet接收TCP结果，但是我们没有读取流，这是在缓冲中积累起来的吗？这是如何导致摄像头锁定的？我仍然不能回答这些问题。

我们向客户部署了新版本的软件，在撰写本文时，它已经运行了近一年，不需要进一步修改。从那时起，它已经生产了大约1000万件产品。我从中学到的是负载测试的重要性。我们测试了机器，但没有达到所需的水平。我们在办公室运行了几千个产品，但客户希望在一定时间内批处理运行180k个产品，我们没有测试过任何接近这个水平的连续操作。

从那以后，我们询问每个客户最大的批量处理有多少，然后我们用两倍的量来测试。

原文链接：My hardest bug to debug

创作场景

我经历过的最难调试的 Bug