fix Issue 14036 - Do not throw FinalizeError on OutOfMemoryError or Inva...

[CyberShadow]

...lidMemoryOperationError

This changes FinalizeError to be thrown only when an Exception is thrown,
with the disadvantage of not catching non-Exception Throwables and the
advantage of preserving the stack trace for the code that caused
InvalidMemoryOperationError.

https://issues.dlang.org/show_bug.cgi?id=14036

[CyberShadow]

CC @MartinNowak

[rainers]

I guess you'll have to catch the memory error to successfully pass the unittest.

[rainers]

I agree that not catching Errors is better.
Slightly related: we should use some special assert inside the GC to avoid an InvalidMemoryError because onAssertError is allocating.

[CyberShadow]

Finally fixed tests.

[MartinNowak]

Auto-merge toggled on

[MartinNowak]

Why was the stacktrace of Throwable.next missing?

[CyberShadow]

We can allocate neither a stack trace nor a FinalizeError in an InvalidMemoryOperation condition.

[CyberShadow]

To clarify, I was talking about the stack trace in the debugger. If we catch and rethrow, the stack trace of the point where the exception was thrown is lost (unless it was saved in the exception object, which it was not).

[Orvid]

With an InvalidMemoryError or OutOfMemoryError, would it be a viable choice to simply claim that all memory currently allocated is free to be used by the runtime to output useful information, such as a stack trace. Both of these errors are impossible to recover from, so the best we can do is hope that the current state is at least valid enough to be able to use the space for a stack trace.

[CyberShadow]

That might do more harm than good, e.g. corrupt user data.

[CyberShadow]

It would also be easier to use C malloc, or allocate directly from the OS (for the case of InvalidMemoryOperation).

[Orvid]

A short transcript of the ensuing IRC conversation:

CyberShadow: In both of those cases though, there's nothing you can do about it, the program IS going to crash, so why does it matter if we corrupt user data?
The user might be dumb and set up some atexit() handlers OSLT even though they shouldn't
But for it to corrupt their data, they'd have to be using GC allocated memory; As we are already known to be crashing, the entirety of the application's memory should be assumed to be corrupted, we are merely being wishful that the GC's core tables haven't been.

[MartinNowak]

A stack trace for OOM is misleading and InvalidMemoryError will be fixed at some point.
We could probably still use malloc for the stacktrace.