实时调试堆栈溢出 [英] live debugging a stack overflow

问题描述

我有一个托管代码Windows Service应用程序，由于托管StackOverFlowException，该应用程序在生产中偶尔会崩溃。我之所以知道这一点，是因为我已经在崩溃模式下运行了adplus，并使用SoS分析了崩溃转储事后调查。我什至连上了windbg调试器，并将其设置为未处理的异常。

I have a managed code Windows Service application that is crashing occasionally in production due to a managed StackOverFlowException. I know this because I've run adplus in crash mode and analyzed the crash dump post mortem using SoS. I have even attached the windbg debugger and set it to "go unhandled exception".

我的问题是，我看不到任何托管堆栈或切换到任何托管堆栈的线程。

My problem is, I can't see any of the managed stacks or switch to any of the threads. They're all being torn down by the time the debugger breaks.

我不是Windbg专家，而且没有在实时系统上安装Visual Studio或使用使用该工具进行远程调试和调试，是否有人对我如何从有问题的线程中获取堆栈跟踪有任何建议？

I'm not a Windbg expert, and, short of installing Visual Studio on the live system or using remote debugging and debugging using that tool, does anyone have any suggestions as to how I can get a stack trace out of the offending thread?

这就是我正在做的事情。

Here's what I'm doing.

！线程

!threads

...

XXXX 11 27c 000000001b2175f0 b220禁用00000000072c9058：00000000072cad80 0000000019bdd3f0 0 Ukn System.StackOverflowException（0000000000c010d0）

XXXX 11 27c 000000001b2175f0 b220 Disabled 00000000072c9058:00000000072cad80 0000000019bdd3f0 0 Ukn System.StackOverflowException (0000000000c010d0)

...

这时您会看到XXXX ID，表明线程已经死了。

And at this point you see the XXXX ID indicating the thread is quite dead.

推荐答案

一旦遇到堆栈溢出，您就很难调试问题了-耗尽堆栈空间会使程序处于不确定状态，因此您不能依赖的 any 此时的信息-您尝试获取的任何堆栈跟踪都可能已损坏，并且很容易将您指向错误的方向。即，一旦StackOverflowException发生，就为时已晚。

Once you've hit a stack overflow, you're pretty much out of luck for debugging the problem - blowing your stack space leaves your program in a non-deterministic state, so you can't rely on any of the information in it at that point - any stack trace you try to get may be corrupted and can easily point you in the wrong direction. Ie, once the StackOverflowException occurs, it's too late.

此外，根据文档，您将无法从.Net 2.0版本开始捕获StackOverflowException，因此，针对此问题的其他建议可能会用try / catch包围您的代码工作。考虑到堆栈溢出的副作用，这是完全合理的（我很惊讶.Net曾经让您抓住它）。

Also, according to the documentation you can't catch a StackOverflowException from .Net 2.0 onwards, so the other suggestions to surround your code with a try/catch for that probably won't work. This makes perfect sense, given the side effects of a stack overflow (I'm surprised .Net ever allowed you to catch it).

您唯一的选择是参与在分析代码的繁琐工作中，查找可能导致堆栈溢出的所有内容，并放入某种标记，以便您可以在发生它们之前 知道它们的发生位置。例如，显然任何递归方法都是首先开始的，所以给它们一个深度计数器，并在它们达到您定义的某些不合理值时抛出您自己的异常，这样您就可以实际获得有效的堆栈跟踪。

Your only real option is to engage in the tedium of analyzing the code, looking for anything that could potentially cause a stack overflow, and putting in some sort of markers so you can get an idea where they occur before they occur. Eg, obviously any recursive methods are the first place to start, so give them a depth counter and throw your own exception if they get to some "unreasonable" value that you define, that way you can actually get a valid stack trace.

这篇关于实时调试堆栈溢出的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！