Windows exception handler does not survive stack overflows about google-breakpad

[GoogleCodeExporter]

Original comment by [email protected] on 27 Sep 2006 at 9:16

• Added labels: OpSys-Windows

[GoogleCodeExporter]

Original comment by [email protected] on 16 Oct 2006 at 10:19

• Added labels: Milestone-Release1.0

[GoogleCodeExporter]

Note: SetThreadStackGuarantee

Original comment by [email protected] 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 [email protected] 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 [email protected] on 30 Oct 2006 at 10:22

[GoogleCodeExporter]

Original comment by [email protected] on 30 Oct 2006 at 11:27

Attachments:

• airbag.34.1.patch

[GoogleCodeExporter]

[57] checked in.

Original comment by [email protected] 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 [email protected] on 31 Oct 2006 at 4:59