[winedbg] Don't ever pass a NONCONTINUABLE exception

[Glenn Wurster]

> > In short, because we're never going to be able to continue, so there's
> > no point on trying to pass because that's going to fail.
> 
> Not really, if the app handles the exception there's no reason it
> would fail. Not passing the exception will break things like
> IsBadReadPtr.

Ok.  My understanding of the non-continuable flag was not correct.  A
fixed patch follows in a seporate e-mail to wine-patches.

> > In long, because I've got another patch in the pipeline (it needs some
> > tweaking) that moves the calling of the debugger into the signal
> > handler.  It allows the debugger to catch exceptions that would
> > previously have resulted in a total crash (non-continuable
> > exceptions), and it more accurately reflects how the Windows debugger
> > is called.  Using a debugger will also no longer modify program memory
> > as it does currently.  In all, it should allow the debugger to work in
> > more circumstances than it currently does.
> 
> Well, I'll wait to see the patch, but I doubt we want to do that. The
> current way is pretty much identical to what Windows does, and it
> sounds like your way isn't.

Doing SEH via the application stack is correct in the current code.
Passing exceptions to the debugger via the application stack is not
correct.  I've attached a small C file which will demonstrate the
problem.  On windows, you can single step through the assembly code
correctly, on Wine, you can not.  The one conclusion that we can draw
is that the method for calling the debugger on Windows must not use
the application stack at all.  Furthermore, if an exception does occur
while the stack pointer is bad in windows, the debugger will trap it
and let you examine the situation.  Wine right now crashes.

Moving the calling of the debugger into the signal handler takes away
the dependance on a correct signal stack.  It lets us:

1) Debug a program without having to modify it's memory to call the
debugger.

2) Set breakpoints and single step through areas where the stack
pointer is incorrect.

3) Use the debugger even when the application is at it's upper stack
limit (so we can see where the stack overflow exists).

4) Examine exceptions and application state when an exception is
generated while stack pointer is bad.

All these can be done on Windows, and therefore sending events to the
Windows debugger must be done without relying on the program stack.
It would make sense for the wine debugger to be equally capable.

Now, if calling the debugger shifts positions to the signal stack, it
is possible to detect whether we can deliver a corresponding SE to the
applications SEH.  If we can detect when the exception can not
actually be delivered, then we can force the debugger to stop, even if
this is the first notification of a excpetion to the debugger.  The
point behind the non-continuable change was to tell the debugger this.
That patch was wrong.  I should have used EH_STACK_INVALID (it would
be impossible to even pass this flag to the debugger if the debugger
relied on the application stack).

Glenn.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: esp-test.cpp
Type: text/x-c++src
Size: 458 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20050822/ca979b3d/esp-test.cpp