如何保证在Visual Studio 2005下在C ++中捕获EXCEPTION_STACK_OVERFLOW结构化异常？ [英] How can I guarantee catching a EXCEPTION_STACK_OVERFLOW structured exception in C++ under Visual Studio 2005?

问题描述

• 我有一个应用程序使用Poof-Crash [ 1 ]。我相当肯定是由于一个吹起的堆栈。


• 应用程序是多线程的。


• 我正在使用


• 我已经写了一个SE翻译器函数，并调用了 _set_se_translator（）。


• 我已经编写了函数并设置 set_terminate（）和 set_unexpected（）。


• 要获取堆栈溢出，我必须运行在释放模式，在重负载下，几天。在调试器下运行不是一个选项，因为应用程序无法执行足够快的速度来实现运行时所需的查看问题。


• 我可以通过在执行时添加无限递归来模拟问题其中一个功能，因此测试捕获 EXCEPTION_STACK_OVERFLOW 异常。


• 我有WinDBG设置作为崩溃转储程序，获取所有其他崩溃问题的好消息，但不是这一个。崩溃转储将仅包含一个线程，即Sleep（）。所有其他线程已退出。

• I have an application with a Poof-Crash[1]. I'm fairly certain it is due to a blown stack.
• The application is Multi-Threaded.
• I am compiling with "Enable C++ Exceptions: Yes With SEH Exceptions (/EHa)".
• I have written an SE Translator function and called _set_se_translator() with it.
• I have written functions for and setup set_terminate() and set_unexpected().
• To get the Stack Overflow, I must run in release mode, under heavy load, for several days. Running under a debugger is not an option as the application can't perform fast enough to achieve the runtime necessary to see the issue.
• I can simulate the issue by adding infinite recursion on execution of one of the functions, and thus test the catching of the EXCEPTION_STACK_OVERFLOW exception.
• I have WinDBG setup as the crash dump program, and get good information for all other crash issues but not this one. The crash dump will only contain one thread, which is 'Sleep()'ing. All other threads have exited.

我已经尝试导致收到 EXCEPTION_STACK_OVERFLOW 异常。

None of the things I've tried has resulted in picking up the EXCEPTION_STACK_OVERFLOW exception.

有没有人知道如何保证在发布模式的运行期间有机会在这个例外？

Does anyone know how to guarantee getting a a chance at this exception during runtime in release mode?

1. Poof-Crash ：应用程序通过poof崩溃，消失无踪。

1. Poof-Crash: The application crashes by going "poof" and disappearing without a trace.

（考虑到这个网站的名称，我很惊讶，这个问题不在这里！）

1. 一个答案简要介绍了将堆栈大小调整为潜在迫使问题更早，并允许使用调试器捕获它。这是一个聪明的想法，但不幸的是，我不相信会有所帮助。这个问题很可能是导致无限递归的一个角落。缩短堆栈不会更早地将问题暴露出来，并可能导致有效的深层代码中的无关的崩溃。不过，感谢发贴，即使你删除了。

推荐答案

Windows XP之前的一切都不会（或者更难）通常能够陷阱堆栈溢出。随着xp的出现，您可以设置向量异常处理程序在任何基于堆栈（结构化异常）处理程序之前获得堆栈溢出的机会（这是原因 - 结构化异常处理程序是基于堆栈的）。

但是，即使你能够捕获这样的异常，你也可以做很多事情。

在他的博客中，cbrumme（对不起，没有他/她的真实name）讨论了可能用于回退的保护页面（一个生成堆栈溢出）的堆栈页面。如果您可以将您的退出代码压缩成仅使用一个堆栈页面 - 您可以随意更改逻辑允许的空间。否则，应用程序在遇到堆栈溢出时几乎死了。要解决的唯一其他合理的事情是写一个转储文件供以后调试。

Everything prior to windows xp would not (or would be harder) generally be able to trap stack overflows. With the advent of xp, you can set vectored exception handler that gets a chance at stack overflow prior to any stack-based (structured exception) handlers (this is being the very reason - structured exception handlers are stack-based).

But there's really not much you can do even if you're able to trap such an exception.

In his blog, cbrumme (sorry, do not have his/her real name) discusses a stack page neighboring the guard page (the one, that generates the stack overflow) that can potentially be used for backout. If you can squeeze your backout code to use just one stack page - you can free as much as your logic allows. Otherwise, the application is pretty much dead upon encountering stack overflow. The only other reasonable thing to do, having trapped it, is to write a dump file for later debugging.

希望它有帮助。

这篇关于如何保证在Visual Studio 2005下在C ++中捕获EXCEPTION_STACK_OVERFLOW结构化异常？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！