www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why is it so difficult to get a core dump for exceptions/errors?

reply Marenz <dlang supradigital.org> writes:
One thing that bugged me for years in D is how difficult it is to 
get a useful core dump.

A very common situation is that one of your calls fails, throws 
an exception you haven't
anticipated.

The intuitive thing (and the thing that basically all other 
languages do) is to do
whatever the equivalent of `abort()` or `kill -ABRT` is: Do a 
core-dump exit.
An exit of this kind can be caught in the debugger or creates a 
core file which
can be read in the debugger.

I have all state information for every frame, I can investigate 
in detail what's going
on and wrong.

I know there is the `rt_trapExceptions` variable which can be set 
if you go the
complicated way of writing your own main entry function.

But even that doesn't help if the same thing happens to you in a 
Fiber.

My current situation is for example this:

My server application sometimes crashes, the stdout log only 
saying

```
Task terminated with unhandled exception: Invalid memory operation
Full error: 
core.exception.InvalidMemoryOperationError src/core/exception.d(693): Invalid
memory operation
----------------
uncaught exception
dwarfeh(224) fatal error
```

helpfulness: zero. And I already employed the rt_trapExceptions 
trick here.
What I have to do to get a meaningful core dump and thus stack 
trace here is to actually change core/thread.d and make it call 
fibers without the `try/catch` combination.

I think this is pretty terrible in terms of developer-usability 
and it makes it unnecessarily difficult.




Further more, why is it even catching `Error`s? I thought errors 
should never be caught. If it would just catch exceptions that 
would.. still be annoying but at least more acceptable. And the 
rt_trapException switch would then makes it not even catch 
exceptions.

That's what would make sense to me. What I'd consider intuitive 
would be to do no catching at all of course. Or at the very least 
have an easy way to disable it. For fibers AND for main().
Oct 22 2017
parent reply Nemanja Boric <4burgos gmail.com> writes:
On Sunday, 22 October 2017 at 11:16:56 UTC, Marenz wrote:
 One thing that bugged me for years in D is how difficult it is 
 to get a useful core dump.

 ```
 Task terminated with unhandled exception: Invalid memory 
 operation
 Full error: 
 core.exception.InvalidMemoryOperationError src/core/exception.d(693): Invalid
memory operation
 ----------------
 uncaught exception
 dwarfeh(224) fatal error
 ```
What version of compiler/runtime are you using? I've fixed this behaviour (fatal error if no exception handler is found) in v2.076: https://github.com/dlang/druntime/pull/1673 and the fix should actually call abort(): https://github.com/dlang/druntime/pull/1673/files#diff-6c3bc1200b51af9b16b902fd88879ca1R227 Judging from the output (dwarfeh(224) fatal error), this patch is not applied in your runtime.
Oct 22 2017
next sibling parent Nemanja Boric <4burgos gmail.com> writes:
On Monday, 23 October 2017 at 06:48:50 UTC, Nemanja Boric wrote:
 On Sunday, 22 October 2017 at 11:16:56 UTC, Marenz wrote:
 One thing that bugged me for years in D is how difficult it is 
 to get a useful core dump.

 ```
 Task terminated with unhandled exception: Invalid memory 
 operation
 Full error: 
 core.exception.InvalidMemoryOperationError src/core/exception.d(693): Invalid
memory operation
 ----------------
 uncaught exception
 dwarfeh(224) fatal error
 ```
What version of compiler/runtime are you using? I've fixed this behaviour (fatal error if no exception handler is found) in v2.076: https://github.com/dlang/druntime/pull/1673 and the fix should actually call abort(): https://github.com/dlang/druntime/pull/1673/files#diff-6c3bc1200b51af9b16b902fd88879ca1R227 Judging from the output (dwarfeh(224) fatal error), this patch is not applied in your runtime.
As for the core dump - the runtime actually calls abort (pre and post my patch, as it looks like). I'm not aware anything in the runtime handling SIGABRT, are you doing it in your application? Is your system setup to generate core files `ulimit -c unlimited` or similar? You should at least get in your stderr (not stdout) message that the SIGABRT was raised (and you did before IIRC, you've commented it on one PR).
Oct 22 2017
prev sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On Monday, 23 October 2017 at 06:48:50 UTC, Nemanja Boric wrote:
 On Sunday, 22 October 2017 at 11:16:56 UTC, Marenz wrote:
 One thing that bugged me for years in D is how difficult it is 
 to get a useful core dump.

 ```
 Task terminated with unhandled exception: Invalid memory 
 operation
 Full error: 
 core.exception.InvalidMemoryOperationError src/core/exception.d(693): Invalid
memory operation
 ----------------
 uncaught exception
 dwarfeh(224) fatal error
 ```
What version of compiler/runtime are you using? I've fixed this behaviour (fatal error if no exception handler is found) in v2.076: https://github.com/dlang/druntime/pull/1673 and the fix should actually call abort(): https://github.com/dlang/druntime/pull/1673/files#diff-6c3bc1200b51af9b16b902fd88879ca1R227 Judging from the output (dwarfeh(224) fatal error), this patch is not applied in your runtime.
That or he's hitting one of the other cases. But looking at the line number, seems unlikely. https://github.com/dlang/druntime/blob/e160a6ad90900917010619c944db2d55731b527d/src/rt/dwarfeh.d#L224 Perhaps dmd druntime could be smarter here and also dump the stack trace to stderr. But first, updates your compiler.
Oct 23 2017
parent Nemanja Boric <4burgos gmail.com> writes:
On Monday, 23 October 2017 at 07:27:03 UTC, Iain Buclaw wrote:
 On Monday, 23 October 2017 at 06:48:50 UTC, Nemanja Boric wrote:
 On Sunday, 22 October 2017 at 11:16:56 UTC, Marenz wrote:
 One thing that bugged me for years in D is how difficult it
Perhaps dmd druntime could be smarter here and also dump the stack trace to stderr.
It does as of v2.076: https://github.com/dlang/druntime/blob/e160a6ad90900917010619c944db2d55731b527d/src/rt/dwarfeh.d#L226
Oct 23 2017