Windows exception handler does not survive stack overflows

[GoogleCodeExporter]

The current Windows exception handler runs on the same thread that took the
exception.  If stack space is nearly exhausted (for example, when a crash
is caused by infinite recursion), the exception will not be fully handled.
 MiniDumpWriteDump will not complete.

We want to handle this case.

When an exception occurs, we are able to execute a small amount of code on
the same thread and stack that took the exception.  This code should
transfer control to a background handler thread, or move the stack to some
preallocated buffer of sufficient size.  The former's probably cleaner, and
doable entirely with standard OS calls.  The latter requires CPU-specific asm.

Original issue reported on code.google.com by mmento...@gmail.com on 27 Sep 2006 at 9:15

[GoogleCodeExporter]

Original comment by mmento...@gmail.com on 27 Sep 2006 at 9:16

• Added labels: OpSys-Windows

[GoogleCodeExporter]

Original comment by bry...@gmail.com on 16 Oct 2006 at 10:19

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

Note: SetThreadStackGuarantee

Original comment by mmento...@gmail.com on 18 Oct 2006 at 8:18

[GoogleCodeExporter]

Ugh, SetThreadStackGuarantee isn't available for x86 prior to Server 2003 SP1 
and
Vista.  It's not in XP.

Original comment by mmento...@gmail.com on 18 Oct 2006 at 10:04

[GoogleCodeExporter]

Here's some really ugly code for doing this on systems without that API:
http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B315937

Original comment by ted.mielczarek on 19 Oct 2006 at 6:29

[GoogleCodeExporter]

I'm working on this.

I've got it working by creating a special exception-handling thread, which of 
course
has its own stack.  I've made the handler (which executes on the exception 
thread)
into a critical section and am using semaphores to synchronize the exception 
thread
with the new handler thread.  This is all working properly.

The dumped thread state for the handler thread is, not surprisingly, garbage.  
Since
we can't easily filter this out on the exception handler side on Windows when 
we're
using MiniDumpWriteDump, I propose adding a new stream to the minidump that 
carries
the thread ID of the handler thread, so that MinidumpProcessor can filter this 
thread
out.  This stream can be merged with what I want to do in #57.

The new stream should block 1.0, but I'll do the work in separate bugs.

Original comment by mmento...@gmail.com on 30 Oct 2006 at 10:22

[GoogleCodeExporter]

Original comment by mmento...@gmail.com on 30 Oct 2006 at 11:27

Attachments:

• airbag.34.1.patch

[GoogleCodeExporter]

[57] checked in.

Original comment by mmento...@gmail.com on 31 Oct 2006 at 4:50

• Changed state: Fixed

[GoogleCodeExporter]

Per comment 6, regarding keeping the extra thread from showing up in processed 
dump
output: #57 to add the necessary data to minidumps on the client handler side, 
and
#65 to make use of that data on the processor side.

Original comment by mmento...@gmail.com on 31 Oct 2006 at 4:59