Since the application will probably have to stop, might as well use the GC:

in GC:

if (gcx.running) {
    gcx.running = false;
    onInvalidMemoryOperationError();
}

in core.exception:

throw new InvalidMemoryOperationError();

And there you go, a beautiful stack trace. I now have a pinpoint of the error within 100k++ LOC. Thank you.

Why D? Why fail with a one line message and no debug tools? Why??

On Thursday, 4 June 2015 at 23:56:28 UTC, Etienne wrote:
> Since the application will probably have to stop, might as well use the GC:
>
> in GC:
>
> if (gcx.running) {
>     gcx.running = false;
>     onInvalidMemoryOperationError();
> }
>
> in core.exception:
>
> throw new InvalidMemoryOperationError();
>
> And there you go, a beautiful stack trace. I now have a pinpoint of the error within 100k++ LOC. Thank you.
>
> Why D? Why fail with a one line message and no debug tools? Why??

I don't understand what you're grieving about, but:

1. We can't show a stack trace in an InvalidMemoryOperationError situation because we need to allocate memory for the stack trace, which we can't do in an InvalidMemoryOperationError situation.

2. Hope this helps: http://wiki.dlang.org/InvalidMemoryOperationError

On Thursday, 4 June 2015 at 23:59:11 UTC, Vladimir Panteleev wrote:
> On Thursday, 4 June 2015 at 23:56:28 UTC, Etienne wrote:
>> Since the application will probably have to stop, might as well use the GC:
>>
>> in GC:
>>
>> if (gcx.running) {
>>    gcx.running = false;
>>    onInvalidMemoryOperationError();
>> }
>>
>> in core.exception:
>>
>> throw new InvalidMemoryOperationError();
>>
>> And there you go, a beautiful stack trace. I now have a pinpoint of the error within 100k++ LOC. Thank you.
>>
>> Why D? Why fail with a one line message and no debug tools? Why??
>
> I don't understand what you're grieving about, but:
>
> 1. We can't show a stack trace in an InvalidMemoryOperationError situation because we need to allocate memory for the stack trace, which we can't do in an InvalidMemoryOperationError situation.
>
> 2. Hope this helps: http://wiki.dlang.org/InvalidMemoryOperationError

Apparently GDB couldn't stack trace the error with symbols, was limited to 2 frames without symbols:
http://forum.dlang.org/thread/joefjvuxpvwsfozvykgu@forum.dlang.org#post-rpnmeklflyzodhfehari:40forum.dlang.org
http://forum.dlang.org/thread/joefjvuxpvwsfozvykgu@forum.dlang.org?page=2#post-pjntbqmxjbyxiwevdlra:40forum.dlang.org

The error also didn't occur in Windows so I couldn't use that.

I think you're mixing up the "invalid state" and "unusable". The GC is fully usable for the purpose of throwing, because I got a 35 frame stack trace from it.

On Friday, 5 June 2015 at 00:04:00 UTC, Etienne wrote:
> On Thursday, 4 June 2015 at 23:59:11 UTC, Vladimir Panteleev wrote:
>> On Thursday, 4 June 2015 at 23:56:28 UTC, Etienne wrote:
>>> [...]
>>
>> I don't understand what you're grieving about, but:
>>
>> 1. We can't show a stack trace in an InvalidMemoryOperationError situation because we need to allocate memory for the stack trace, which we can't do in an InvalidMemoryOperationError situation.
>>
>> 2. Hope this helps: http://wiki.dlang.org/InvalidMemoryOperationError
>
> Apparently GDB couldn't stack trace the error with symbols, was
> limited to 2 frames without symbols:
> http://forum.dlang.org/thread/joefjvuxpvwsfozvykgu@forum.dlang.org#post-rpnmeklflyzodhfehari:40forum.dlang.org
> http://forum.dlang.org/thread/joefjvuxpvwsfozvykgu@forum.dlang.org?page=2#post-pjntbqmxjbyxiwevdlra:40forum.dlang.org
>
> The error also didn't occur in Windows so I couldn't use that.

Couldn't use what? The article provides information for both Windows and Linux.

> I think you're mixing up the "invalid state" and "unusable". The GC is fully usable for the purpose of throwing, because I got a 35 frame stack trace from it.

Invalid state == unusable. We need to be extremely careful in memory corruption conditions. For example, if the application has a memory-mapped file, we can corrupt data on disk if we're careless.

On Thursday, 4 June 2015 at 23:56:28 UTC, Etienne wrote:
> Why D? Why fail with a one line message and no debug tools? Why??

this has been making my research project hilariously difficult...
something goes wrong? too bad, enjoy your crash with no stack trace.

On Friday, 5 June 2015 at 00:22:25 UTC, Vladimir Panteleev wrote:
> Invalid state == unusable. We need to be extremely careful in memory corruption conditions. For example, if the application has a memory-mapped file, we can corrupt data on disk if we're careless.

Well that's probably why it should inherit Throwable then. There's no good reason to care more about the experimental program than about the mental health of the programmer writing it.

On Friday, 5 June 2015 at 00:41:37 UTC, Etienne wrote:
> Well that's probably why it should inherit Throwable then.

Why?

> There's no good reason to care more about the experimental program than about the mental health of the programmer writing it.

Maybe one day we'll start including a debug version of the standard library with the distribution, with stack frames and stuff.

DMD has had a -debuglib switch for a while, but it's not used in default installations.

On Friday, 5 June 2015 at 00:45:01 UTC, Vladimir Panteleev wrote:
> On Friday, 5 June 2015 at 00:41:37 UTC, Etienne wrote:
>> Well that's probably why it should inherit Throwable then.
>
> Why?
>
>> There's no good reason to care more about the experimental program than about the mental health of the programmer writing it.
>
> Maybe one day we'll start including a debug version of the standard library with the distribution, with stack frames and stuff.
>
> DMD has had a -debuglib switch for a while, but it's not used in default installations.

I compiled debug version of druntime, phobos and I'm an expert with GDB. That's not the issue. The issue is that D has become knee-deep with technicals implementing a new attribute for every edge case but forgetting that the average programmer wants a little arrow pointing at their mistakes.

I mean come on here, I made a fatal error and my application is overdue for crashing every thread and D is so broken that it adds a deadlock on top of that, and you're telling me you'll feel guilty for allocating the stack trace on the GC because it's in an invalid state. Something is simply wrong with the community culture as a whole if that's the case.

On Friday, 5 June 2015 at 01:07:28 UTC, Etienne wrote:
> I mean come on here, I made a fatal error and my application is overdue for crashing every thread and D is so broken that it adds a deadlock on top of that, and you're telling me you'll feel guilty for allocating the stack trace on the GC because it's in an invalid state.

There probably wouldn't be any problem with using the C heap or something. Using the GC is just making it likely to crash while trying to allocate it.

> Something is simply wrong with the community culture as a whole if that's the case.

http://forum.dlang.org/post/nkwpjnydlqnnpsxsttto@forum.dlang.org

On 2015-06-04 21:12, Vladimir Panteleev wrote:
> On Friday, 5 June 2015 at 01:07:28 UTC, Etienne wrote:
>> I mean come on here, I made a fatal error and my application is
>> overdue for crashing every thread and D is so broken that it adds a
>> deadlock on top of that, and you're telling me you'll feel guilty for
>> allocating the stack trace on the GC because it's in an invalid state.
>
> There probably wouldn't be any problem with using the C heap or
> something. Using the GC is just making it likely to crash while trying
> to allocate it.
>
>> Something is simply wrong with the community culture as a whole if
>> that's the case.
>
> http://forum.dlang.org/post/nkwpjnydlqnnpsxsttto@forum.dlang.org

Nice, this is RESOLVED WONTFIX

I better keep a druntime patch aside then.