如何在代码工作流程中出现问题时快速调试？

Question

我经常遇到以下调试方案：

Tester为bug提供了一些重现步骤。为了找出问题所在，我尝试使用这些重现步骤来获得最少的必要重现步骤。有时，幸运的是我发现当对步骤进行微小改动时，问题就消失了。

然后，作业转而在这两个重现步骤之间找到代码工作流程的差异。这项工作既繁琐又痛苦，特别是当您处理大型代码库并且它经历了大量代码并涉及许多您不熟悉的状态更改时。

所以我想知道是否有可用于比较“代码工作流程”的工具。当我在WinDbg中学习了“wt”命令时，我认为可能会这样做。例如，我可以使用2个不同的重现步骤在大多数函数上运行“wt”命令，然后比较输出之间的差异。然后很容易找到代码流开始分歧的地方。

但是WinDBG的问题是“wt”很慢（也许我应该使用日志文件而不是输出到屏幕）并且不是非常用户友好（与visual studio调试器相比）......所以我想问一下你们有现成的工具吗？或者为Visual Studio调试器开发“插件”以支持此功能是否可能也很困难？

谢谢

Answer 1

我在“覆盖”模式下在探查器下运行它，然后在结果上使用diff来查看代码的哪些部分在一次运行中执行而不是另一次运行。

Answer 2

很抱歉，我不知道哪种工具可以做你想做的事情，但即使它存在，它听起来也不是找出低层代码失败的最快方法。

我建议使用高级日志检测图层的代码，以便了解哪个模块出现故障，停止等等。在调试中，您的记录器可以写入文件，输出调试窗口等。

一般来说，快速失败并使用例外是很容易找到问题的好方法。

Answer 3

事后做一些事情不会削减它，因为你的问题正在复制它。

错误的问题很少是一些内部的怪癖，但通常是用户实际做的事情。如果您记录用户输入的所有命令，那么他们只需向您发送日志即可。您可以替换按钮单击，鼠标选择等。这将有一些成本，但肯定远低于跟踪每个访问过的方法。

Answer 4

我假设你有一个大型应用程序，你有良好的日志记录或跟踪。

我在一个拥有40多个进程和超过一百万行代码的大型服务器产品上工作。大多数情况下，跟踪文件中的错误足以识别问题的位置。但是，有时我在跟踪文件中看到的错误是由一些早期代码引起的，其原因很难发现。然后我使用比较调试技术：

• 重现第一个场景，将跟踪复制到新文件（如果应用程序是多线程的，请确保您只有执行工作的线程的跟踪）。
• 重现第二种情况，将跟踪复制到新文件。
• 从日志文件中删除时间戳（我为此使用awk或sed）。
• 将日志文件与winmerge或类似文件进行比较，以查看它们的分歧位置和方式。

这种技术可能耗费一些时间，但比调试器中的数千行更快。

另一种有用的技术是从跟踪文件生成uml序列图。为此，您需要始终记录功能进入和退出位置。然后编写一个小脚本来解析跟踪文件，并使用sequence.jar生成uml图作为png文件。这是了解一段时间内未触及的代码逻辑的好方法。我在一个批处理文件中包装了一个小的awk脚本，我只提供了跟踪文件和行号，然后它开始解开线程并生成输入文本到sequence.jar然后运行它来创建uml图。