Bug 15886 – Add an uncaught exception handler

The runtime should provide a hook for uncaught exceptions which will be executed BEFORE the stack is unwound, when rt_trapExceptions is set to 0. Currently, it is too difficult to get a debugger on a live program for an uncaught exception before the stack has been unwound. Unwinding the stack means that function arguments and local variables from the program's state at the point when the exception is thrown is not accessible. Currently, rt.dwarfeh calls terminate(__LINE__) which calls abort(), rt.deh_win64_posix calls terminate() which halts, and deh_win32 passes the exception to the OS (which shows the standard Windows "program has stopped working" dialog). Although it's possible to trap these in a debugger by breakpointing the relevant functions from Druntime, doing so is platform-dependent and vulnerable to breaking due to changes in Druntime, such as the recent dwarf EH switch.

> Currently, rt.dwarfeh calls terminate(__LINE__) which calls abort() If abort() is called that will — outside of a debugger — create a core dump allowing you to investigate the memory state at the place where the exception was thrown. I don't see why you would need a hook here?

The bigger problems I found are that you can't set rt_trapExceptions to 0 from inside your program or through environment variables / command line parameters. So you never actually have a core dump generated other then when started through a debugger (the comments for that variable claim a debugger would set it to 0). Another problem is that fibers also have an exception trap so the switch doesn't even have an effect there. That's why I created https://github.com/D-Programming-Language/druntime/pull/1538 and https://github.com/D-Programming-Language/druntime/pull/1537

(In reply to Marenz from comment #1) > > Currently, rt.dwarfeh calls terminate(__LINE__) which calls abort() > > If abort() is called that will — outside of a debugger — create a core dump > allowing you to investigate the memory state at the place where the > exception was thrown. > > I don't see why you would need a hook here? A hook is not *NEEDED* but it sure as heck will help. It's very difficult to print the exception object from within abort()'s stack frame, because the exception object may be optimized out and not easily available from the debugger. (In reply to Marenz from comment #2) > The bigger problems I found are that you can't set rt_trapExceptions to 0 > from inside your program or through environment variables / command line > parameters. Yes, that would be nice (though it does not absolve my need for this enhancement). It's trivial to set it from within gdb (break main / run / set rt_trapExceptions=0 / continue). It could probably also be made settable via environment variables or the command line, like the GC tuning parameters. > That's why I created > > https://github.com/D-Programming-Language/druntime/pull/1538 > > and > > https://github.com/D-Programming-Language/druntime/pull/1537 Nice.

>It's very difficult to print the exception object from within abort()'s stack frame, because the exception object may be optimized out and not easily available from the debugger. Hm that seems true, I don't seem to be getting any access to it at all because the druntime is not compiled with debugging I guess. But do you really need that if you have the whole stack available including the place where it was thrown from?

Well, yes, exception objects often contain information about the error which otherwise can be difficult to obtain directly from the debugger, such as the error message (obviously), the file name / line number where the exception was created (which may not be in the stack trace), and other exception fields for custom exception types.

THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/17326 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB