当代码工作流程出现问题时如何快速调试？
我经常遇到以下调试场景：
测试人员为错误提供了一些重现步骤。为了找出问题所在，我尝试使用这些重现步骤以获得最少的必要重现步骤。有时，幸运的是，我发现只要稍微改变一下步骤，问题就消失了。
然后工作转向找出这两个重现步骤之间代码工作流程的差异。这项工作是乏味且痛苦的，尤其是当您正在处理大型代码库并且它要经历大量代码并涉及大量您不熟悉的状态更改时。
所以我想知道是否有任何工具可用于比较“代码工作流程”。当我在 WinDbg 中学习了“wt”命令时，我认为可能可以做到这一点。例如，我可以使用 2 个不同的重现步骤对大多数函数运行“wt”命令，然后比较输出之间的差异。然后应该很容易找到代码流开始分歧的地方。
但是WinDBG的问题是“wt”非常慢（也许我应该使用日志文件而不是输出到屏幕）并且不太用户友好（与Visual Studio调试器相比）......所以我想问你们是有任何可用的现有工具。或者为 Visual Studio 调试器开发一个“插件”来支持此功能是否可能且困难？
谢谢
I have frequently encounter the following debugging scenario:
Tester provide some reproduce steps for a bug. And to find out where the problem is, I try to play with these reproduce steps to get the minimum necessary reproduce steps. Sometimes, luckily I found that when do a minor change to the steps, the problem is gone.
Then the job turns to find the difference in code workflow between these two reproduce steps. This job is tedious and painful especially when you are working on a large code base and it go through a lot code and involve lots of state changes which you are not familiar with.
So I was wondering is there any tools available to compare "code workflow". As I've learned the "wt" command in WinDbg, I thought it might be possible to do it. For example, I can run the "wt" command on some out most functions with 2 different reproduce steps and then compare the difference between outputs. Then it should be easy to found where the code flow starts to diverge.
But the problem with WinDBG is "wt" is quite slow (maybe I should use a log file instead of output to screen) and not very user-friendly (compared with visual studio debugger) ... So I want to ask you guys is there any existing tools available . or is it possible and difficult to develop a "plug-in" for visual studio debugger to support this functionality ?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我会在“覆盖”模式下的探查器下运行它，然后对结果使用 diff 来查看代码的哪些部分在一次运行中由另一次运行执行。
I'd run it under a profiler in "coverage" mode, then use diff on the results to see which parts of the code were executed in one run by not the other.
抱歉，我不知道有什么工具可以满足您的要求，但即使它存在，它听起来也不是找出底层代码失败的最快方法。
我建议使用高级日志来检测层的代码，以便您可以知道哪个模块失败、停止等。在调试中，您的记录器可以写入文件、输出调试窗口等。
一般来说，快速失败并使用异常是轻松找出问题所在的好方法。
Sorry, I don't know of a tool which can do what you want, but even if it existed it doesn't sound like the quickest approach to finding out where the lower layer code is failing.
I would recommend to instrument your layer's code with high-level logs so you can know which module fails, stalls, etc. In debug, your logger can write to file, to output debug window, etc.
In general, failing fast and using exceptions are good ways to find out easily where things go bad.
事后做某事并不能解决问题，因为你的问题是重现它。
错误的问题很少是内部的怪异，而是通常是用户实际在做什么。如果您记录用户输入的所有命令，那么他们可以简单地将日志发送给您。您可以替代按钮单击、鼠标选择等。这会产生一些成本，但肯定比跟踪每个访问的方法要少得多。
Doing something after the fact is not going to cut it, since your problem is reproducing it.
The issue with bugs is seldom some interal wackiness but usually what the user's actually doing. If you log all the commands that the user enters then they can simply send you the log. You can substitute button clicks, mouse selects, etc. This will have some cost but certainly much less than something that keeps track of every method visited.
我假设如果您有一个大型应用程序，那么您就有良好的日志记录或跟踪。
我开发的大型服务器产品有 40 多个进程和超过 100 万行代码。大多数时候，跟踪文件中的错误足以确定问题的位置。然而，有时我在跟踪文件中看到的错误是由一些早期代码引起的，并且其原因可能很难发现。然后我使用比较调试技术：
这种技术可能有点耗时，但比在调试器中单步执行数千行要快得多。
另一种有用的技术是从跟踪文件生成 uml 序列图。为此，您需要一致记录函数进入和退出位置。然后编写一个小脚本来解析跟踪文件并使用 sequence.jar 来生成 png 文件形式的 uml 图。这是理解您一段时间未接触过的代码逻辑的好方法。我将一个小的 awk 脚本包装在一个批处理文件中，我只提供跟踪文件和行号来启动，然后它解开线程并生成 sequence.jar 的输入文本，然后运行它来创建 uml 图。
I am assuming that if you have a large application that you have good logging or tracing.
I work on a large server product with over 40 processes and over one million lines of code. Most of the time the error in the trace file is enough to identify the location of problem. However sometimes the error I see in the trace file is caused by some earlier code and the reason for this can be hard to spot. Then I use a comparative debugging technique:
This technique can be a little time consuming, but is much quicker than stepping through thousand of lines in the debugger.
Another useful technique is producing uml sequence diagrams from trace files. For this you need the function entry and exit positions logged consistently. Then write a small script to parse your trace files and use sequence.jar to produce uml diagrams as png files. This is a great way to understand the logic of code you haven't touched in a while. I wrapped a small awk script in a batch file, I just provide trace file and line number to start then it untangles the threads and generates the input text to sequence.jar then runs its to create the uml diagram.