Bug 4385 – Uncaught exceptions should call abort() at the place where the exception was thrown

Right now an uncaught exception just prints the exception name (or the backtrace in the better case) and make the program exit with status 1. This is really bad for debugging purposes, and specially harmful for the assert statement. I find the assert statement close to useless because this limitation, because I can't inspect the dead program to see what happened as one usually do with C++ (which calls abort when there is an uncaught exception, resulting in a core dump). I'm finding myself removing asserts (specially when they test for null pointers, as the null pointer gives me a dump eventually) or doing a custom assert that calls C's abort(). PS: I'm marking this as a druntime issue even when applies to D1 because it is a runtime issue (and maybe nobody wants to touch Phobo's 1 runtime).

I just saw changeset 341 (http://www.dsource.org/projects/druntime/changeset/341), thanks for giving this issue some attention. But unless I'm missing something, this change doesn't help much, because the core will be at the point the call to abort() was made, that (again unless I'm missing something) won't be deep in the call stack, where the throw was done. Having a core dumped where the *throw* was made is what is really valuable, as it let you analyze the dead program in the point where it really died. I don't know how hard would be to achieve this, I just know is possible because the C++ runtime (GCC at least) do it.

Oh you're right. It works in C++ because C++ doesn't auto-report uncaught exceptions, so when one passes out of main the process exits in some special manner that preserves the call stack. What I don't get is why this works with object dtors that are run as the stack unwinds though. In any case, druntime has an extern (C) bool called rt_trapExceptions that is used by debuggers to enable some of this functionality, but it has to be set very early in the startup process. I guess I'll have to think about this one some more.

(In reply to comment #2) > Oh you're right. It works in C++ because C++ doesn't auto-report uncaught > exceptions, GCC does, when using the verbose termination handler (which has been the default for some time now): http://gcc.gnu.org/onlinedocs/libstdc++/manual/bk01pt02ch06s02.html > so when one passes out of main the process exits in some special > manner that preserves the call stack. What I don't get is why this works with > object dtors that are run as the stack unwinds though. In any case, druntime > has an extern (C) bool called rt_trapExceptions that is used by debuggers to > enable some of this functionality, but it has to be set very early in the > startup process. I guess I'll have to think about this one some more. OK, thanks.

Why not call abort from onAssertError function? (In reply to comment #2) > What I don't get is why this works with > object dtors that are run as the stack unwinds though. If I remember it correctly, objects are destructed during the catch phase. I think, this won't work with sjlj exceptions.

FYI I have it working perfectly in Tango/D1 (I even print a stack trace). If you're interested I can share the code.

I think this is already possible by setting rt_trapExceptions=0 (BEFORE the runtime is initialized, i.e. from a debugger), then breakpointing abort() / rt.deh_win64_posix.terminate() / etc. Reopen if this is still an issue. I've filed a related issue 15886.

Reading this, https://issues.dlang.org/show_bug.cgi?id=15894 and https://issues.dlang.org/show_bug.cgi?id=15895 are probably related as well.