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

From: David Abrahams (abrahams_at_[hidden])
Date: 2000-05-28 11:11:52

----- Original Message -----
From: "Mario Contestabile" <marioc_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Sunday, May 28, 2000 11:23 AM
Subject: Re: [boost] solution: Microsoft JIT debugging and catch(...)

> Re-Throwing the last exception in your structured Exception handler, I've
> never seen that idiom.

The last exception is the structured exception (i.e. the crash). It's just
the same as not installing a se_translator, except that the debugger gets
invoked. The really novel thing I'm doing, AFAICT, is to call
UnhandledExceptionFilter from within my se_translator function.

> With Visual C++, a catch(...) handler traps all exceptions regardless of
> whether they were generated by a C++ throw or by the os.

Of course I knew that, or we wouldn't be discussing this. That's part of the
problem I was trying to solve.

> Here is your applet
> re-organised to use MSVC's translator functionality, and a catch all
clause.

My applet already uses MSVC's translator functionality and a catch all
clause. I'm not sure I see your point here.

> See
>
http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_crt__set_se_t
> ranslator.htm
>
http://msdn.microsoft.com/library/devprods/vs6/visualc/vccore/_core_exceptio
> n_handling_differences.htm
> for a good explanation.

Yes, I am familiar with these articles. I spent hours going through the MSDN
CD hunting for ways around my JIT problem. An even hairier and more detailed
explanation of things is available at:
http://msdn.microsoft.com/library/periodic/period97/pietrek.htm

But none of these address the JIT debugging problem directly. The real hint
came when I found:
http://msdn.microsoft.com/library/periodic/period96/S1D4F.htm

The first Q&A discusses a problem where a structured exception (actually a
DebugBreak) is being absorbed, and thus hidden from the programmer.

> In my apps, I always use SetUnhandledExceptionFilter(), so when the app
dies
> I obtain the address (in_ExceptionInfo->ExceptionRecord->ExceptionAddress)
&
> the cause (in_ExceptionInfo->ExceptionRecord->ExceptionCode), and give the
> user the option of uploading that info to me.

That's nice for release mode, but at that point lots of information is
already gone (the state of the program, stack backtrace). I guess Dr. Watson
covers those needs, but I think you have to anticipate a problem and have it
running (?)

> Although other os' may have
> such translator functionality, I prefer to have straightforward catch
> clauses throughout the code, and leave such os tricks in the implementors
> hands.

I guess I don't see what you're trying to say here.
I am only using straightforward catch clauses. I too would prefer to leave
OS tricks to implementors. If the implementor didn't interfere with
debugging for me by making a crash equivalent to a C++ exception, I wouldn't
feel the need to meddle at all.

> Mario Contestabile
> MarioC_at_[hidden]
>
> #include <iostream>
> #include <windows.h>
>
> class SE_Exception {
> private:
>     SE_Exception() {}
>     SE_Exception( SE_Exception& ) {}
>     unsigned int nSE;
> public:
>     SE_Exception(unsigned int n) : nSE(n) {}
>     ~SE_Exception() {}
>     unsigned int getSeNumber() { return nSE; }
> };

that's novel; an exception without a public copy constructor. Of course you
realize that throwing such a beast is not conforming. I suppose that doesn't
matter because this is a vendor-specific operation... but what does it do?
If you invoke the private copy constructor, the exception code is lost....

<more MSDN boilerplate snipped>

-Dave