Re: [boost] solution: Microsoft JIT debugging and catch(...)

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-05-30 06:49:37

----- Original Message -----
From: "Guy Bolton King" <guyk_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, May 30, 2000 6:50 AM
Subject: Re: [boost] solution: Microsoft JIT debugging and catch(...)

> This has been a bugbear of mine for some time, and was the topic of a
> thread on the accu-general mailing list earlier this year.
> Interestingly enough, David, your solution is significantly less
> complicated than mine, and seems to do the job fine.  I have one gripe,
> and that is the call to UnhandledExceptionFilter() in your
> se_translator() function.

Well, that's what makes the whole thing work[sic.. read on], so love it or
leave it I guess ;)

> The next paragraph has some SEH-specific jargon; a read of the relevant
> sections of the SDK and/or the mentioned article is _very_ useful.
>
> A quick (hoho) rereading of Matt Austern's classic "Crash Course on the
                                   ^^^^^^^ Pietrek
An understandable error, though, considering Matt Austern's writing has been
such a staple of the Windows development world [hoho] ;)

> Depths of Win32 Structured Exception Handling" (MSJ, January 1997) shows
> that a faulting process that has no exception filters returning
> EXCEPTION_EXECUTE_HANDLER will have UnhandledExceptionFilter() called in
> the _filter_ of the exception handler that wraps the call to the entry
> point of the process.  The fact that it is called in the filter is very
> important; it means that OS's exception-handler dispatch function
> (RtlDispatchException()) hasn't yet attempted to unwind the stack, so
> when the debugger attaches, all is well.
>
> Therefore, your call to UnhandledExceptionFilter() shouldn't be
> necessary, as you'll see if you comment it out.

I didn't believe you at first, but I tested it and by god, you're right! A
one-line fix is better than a 2-line fix!!

> As to how that `throw' in your se_translator() is magic, I don't know.
> I tried to look at the dissassembly of __CxxFrameHandler and
> __InternalCxxFrameHandler, but my EULA-violation-sensitive sunglasses
> went black (or rather, like you, I find this mucking about a tad
> tedious).  At a guess, a re-throw from an se_translator marks the
> exception as unhandlable by catch(...) blocks.
>
> Two issues remain: se_translators are thread-local, so
> _set_se_translator must be called for every new thread.  My
> minimally-intrusive solution involves an iostream-style static
> initialiser for the main thread, and a replacement _beginthreadex().
>
> Of course, I too have been thinking about writing this up; getting round
> to it has been another matter.

Why don't we co-author? You obviously know a lot more about the Windows
internals issues than I do. I consider your contribution at least as great
as mine, since I was flailing in the dark and you picked out the line that
makes the difference. If we give a thread-complete solution people will like
us _so_ much better.

-Dave