Glenn Wurster gwurster@scs.carleton.ca writes:
Changelog: Don't pass on non-continuable exceptions.
Why do you want to do that?
Changelog: Don't pass on non-continuable exceptions.
Why do you want to do that?
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.
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.
Glenn
Glenn Wurster gwurster@scs.carleton.ca writes:
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.
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.
Alexandre Julliard wrote:
Not really, if the app handles the exception there's no reason it would fail.
And that's just what safedisc does so please don't change it because it appears to work and enough things it needs are broken already.
Ivan
Not really, if the app handles the exception there's no reason it would fail.
And that's just what safedisc does so please don't change it because it appears to work and enough things it needs are broken already.
I'm not looking to change exception handling at the application level, just trying to make the debugger work better. Again, EXCEPTION_NONCONTINUABLE was the wrong flag to check, EH_STACK_INVALID is what the revised patch checks, because exceptions with this flag will never make it to the application at all anyway.
Glenn.
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.
Glenn Wurster gwurster@scs.carleton.ca writes:
Moving the calling of the debugger into the signal handler takes away the dependance on a correct signal stack. It lets us:
- Debug a program without having to modify it's memory to call the
debugger.
- Set breakpoints and single step through areas where the stack
pointer is incorrect.
- Use the debugger even when the application is at it's upper stack
limit (so we can see where the stack overflow exists).
- 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.
Sure, that would be nice, just be aware that it's not acceptable to break anything in the normal exception handling semantics, since that has to always take priority over the debugger support. Also note that we used to handle exceptions on the signal stack, and it was causing lots of problems, which is why I'm a bit skeptical. Now, doing only the first chance bit on the signal stack would probably be easier, but it's still far from trivial...
-
Alexandre Julliard -
Glenn Wurster -
Ivan Leo Puoti