www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 4385] New: Uncaught exceptions should dump a core

reply d-bugmail puremagic.com writes:
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



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: -------
Jun 24 2010
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4385




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: -------
Jul 20 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4385




---
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: -------
Jul 21 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4385




PDT ---


 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: -------
Jul 21 2010
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4385




20:13:11 PDT ---
Why not call abort from onAssertError function?



 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: -------
Aug 03 2010
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=4385




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: -------
Dec 22 2011