你如何修复一个你无法复制的错误？

Question

这个问题说明了一切。如果您有多个用户报告的错误，但没有记录日志中发生的错误，也不能重复该错误，无论您如何努力，您如何解决？或者甚至可以吗？

我相信你们当中很多人都会遇到这种情况。你在这种情况下做了什么，最终的结果是什么？

---

编辑： 我对不可修复的错误所做的工作更感兴趣，而不是无法解决的错误。无法解决的错误使得您至少知道存在问题并且在大多数情况下具有搜索它的起点。如果是不可能的，你做什么？你甚至可以做任何事情吗？

Answer 1

Answer 2

如果它是一个GUI应用程序，那么无价值来观察客户生成错误（或尝试）。毫无疑问，他们正在做一些你从未猜到过的事情（不是错误的，只是不同）。

否则，请将您的日志记录集中在该区域。记录大部分内容（您可以稍后将其删除）并让您的应用程序也转储其环境。例如机器类型，VM类型，使用的编码。

您的应用是否报告了版本号，内部版本号等？您需要这个来确定您正在调试的版本（或不是！）。

如果您可以检测您的应用程序（例如，如果您在Java世界中使用JMX），则检测相关区域。存储数据，例如请求+参数，时间等。利用缓冲区存储最后的'n'个请求/响应/对象版本/等等，并在用户报告问题时将其转储出来。

Answer 3

如果您无法复制它，您可以修复它，但无法知道您已经修复它。

我已经最好地解释了错误是如何被触发的（即使我不知道这种情况会如何发生），修复了这一点，并确保如果错误再次出现，我们的通知机制会让未来的开发人员知道我希望我知道的事情。实际上，这意味着在可能触发错误的路径被越过时添加日志事件，并记录相关资源的度量标准。当然，确保测试能够很好地运用代码。

决定要添加哪些通知是可行性和分类问题。因此，首先要决定开发人员花在bug上的时间。如果不知道错误有多重要，就无法回答。

我有很好的结果（没有再出现，代码更好），而且很糟糕（花了太多时间没有解决问题，bug是否已经修复）。这就是估计和发布优先事项的目的。

Answer 4

有时我只需坐下来研究代码，直到找到错误。试着证明这个bug是不可能的，在这个过程中你可能会弄清楚你可能会弄错的地方。如果你真的成功地说服自己这是不可能的，那就假设你搞砸了某个地方。

添加一堆错误检查和断言可能有助于确认或否认您的信念/假设。可能会失败，你永远不会想到。

Answer 5

这可能很困难，有时几乎不可能。但我的经验是，如果你花了足够的时间（如果花费的时间是值得的话），你迟早会能够重现并修复错误。

在这种情况下可能有所帮助的一般性建议。

• 如果可能，请添加更多日志记录，以便下次出现错误时获得更多数据。
• 询问用户是否可以复制错误。如果是的话，你可以让他们在看着他们的肩膀的同时复制它，并希望找出，是什么引发了这个错误。

Answer 6

进行随机更改，直到有效： - ）

Answer 7

思。硬。锁定自己，不承认任何中断。

我曾经有过一个错误，证据是腐败数据库的十六进制转储。指针链被系统地搞砸了。所有用户的程序和我们的数据库软件在测试中完美无缺。我盯着它看了一个星期（它是一个重要的客户），在消除了几十个可能的想法后，我意识到数据分布在两个物理文件中，并且在链越过文件边界的地方发生了损坏。我意识到如果备份/恢复操作在关键点失败，这两个文件可能会结束＆＃34;不同步＆＃34;，恢复到不同的时间点。如果您随后在已经损坏的数据上运行了一个客户程序，它将产生我所看到的指针链。然后，我演示了一系列事件，这些事件完全重现了腐败。

Answer 8

修改您认为问题发生的代码，以便在某处记录额外的调试信息。当下次发生时，您将拥有解决问题所需的一切。

Answer 9

您无法复制两种类型的错误。你发现的那种，以及别人发现的那种。

如果您发现了该错误，您应该能够复制它。如果您无法复制它，那么您根本没有考虑导致该错误的所有因素。这就是为什么每当你有一个bug，你应该记录它。保存日志，获取屏幕截图等。如果不这样做，那么你怎么能证明这个bug确实存在？也许这只是一个虚假的记忆？

如果其他人发现了一个错误，而你无法复制它，显然要求他们复制它。如果他们无法复制它，那么您尝试复制它。如果您无法快速复制它，请忽略它。

我知道这听起来很糟糕，但我认为这是合理的。复制其他人发现的错误所需的时间非常长。如果错误是真实的，它将自然地再次发生。有人，甚至是你，会再次偶然发现它。如果难以复制，那么它也很少见，如果再发生几次，可能不会造成太大的伤害。

如果您花时间实际工作，修复其他错误并编写新代码，那么您可以提高效率，而不是尝试复制一个甚至无法保证实际存在的神秘错误。只要等待它自然再次出现，那么你就可以把所有的时间花在修复它上面，而不是浪费你的时间来试图揭示它。

Answer 10

假设您已经添加了您认为有用的所有日志记录，但它没有......我想到两件事：

1. 从报告的症状向后工作。想想你自己......“我想要产生报告的症状，我需要执行什么样的代码，我将如何实现它，我将如何实现？” D导致C导致B导致A.接受如果错误不可重复，那么正常的方法将无济于事。我不得不盯着代码看了好几个小时，这些思维过程继续发现一些错误。通常它原来是真的愚蠢。

2. 记住鲍勃的第一个调试法则：如果你找不到东西，那是因为你找错了地方： - ）

Answer 11

讨论问题，阅读代码，通常是很多。我们经常成对地做，因为你通常可以很快地分析消除可能性。

Answer 12

首先查看您可以使用的工具。例如，Windows平台上的崩溃转到WinQual，因此如果是这种情况，您现在有崩溃转储信息。您是否可以使用静态分析工具发现潜在的错误，运行时分析工具，分析工具？

然后查看输入和输出。在用户报告错误或输出中任何不合适的情况下，有关输入的类似内容吗？编译报告列表并查找模式。

最后，正如大卫所说，盯着代码。

Answer 13

要求用户为您的计算机提供远程访问权限并自行查看所有内容。要求用户制作一个关于如何重现此错误并将其发送给您的小视频。

当然，两者并非总是可行，但如果它们可能会澄清一些事情。找到错误的常见方法仍然是相同的：分离可能导致错误的部分，试图了解发生了什么，缩小可能导致错误的代码空间。

Answer 14

有像gotomeeting.com这样的工具，您可以使用它们与用户共享屏幕并观察行为。可能存在许多潜在的问题，例如他们的机器上安装的软件数量，某些工具实用程序与您的程序冲突。我认为，网络攻击不是唯一的解决方案，但可能存在超时问题，互联网问题缓慢。

大多数时候我会说软件没有报告正确的错误消息，例如，在java和c＃的情况下跟踪每个例外情况..不要抓住所有但是保留一个点，你可以捕获和记录。除非您使用远程桌面工具，否则UI错误很难解决。而且大多数时候它甚至可能是第三方软件中的错误。

Answer 15

如果你在一个真正重要的应用程序上工作，你可能有1000个错误的队列，其中大部分肯定是可重现的。

因此，我担心我可能会将这个错误关闭为WORKSFORME（Bugzilla），然后继续修复一些更明显的错误。或者做任何项目经理决定做的事情。

当然，进行随机更改是一个坏主意，即使它们是本地化的，因为您冒着引入新错误的风险。