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().

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.

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).

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.

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