http://d.puremagic.com/issues/show_bug.cgi?id=4385

           Summary: Uncaught exceptions should dump a core
           Product: D
           Version: D1 & D2
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: druntime
        AssignedTo: sean@invisibleduck.org
        ReportedBy: llucax@gmail.com


--- Comment #0 from Leandro Lucarella <llucax@gmail.com> 2010-06-24 17:43:57 PDT ---
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).

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4385



--- Comment #1 from Leandro Lucarella <llucax@gmail.com> 2010-07-20 16:32:55 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4385



--- Comment #2 from Sean Kelly <sean@invisibleduck.org> 2010-07-21 07:13:04 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4385



--- Comment #3 from Leandro Lucarella <llucax@gmail.com> 2010-07-21 07:53:06 PDT ---
(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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4385



--- Comment #4 from Sobirari Muhomori <dfj1esp02@sneakemail.com> 2010-08-03 20:13:11 PDT ---
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.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=4385



--- Comment #5 from Leandro Lucarella <llucax@gmail.com> 2011-12-22 15:37:17 PST ---
FYI I have it working perfectly in Tango/D1 (I even print a stack trace). If you're interested I can share the code.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------