On Wednesday, 2 June 2021 at 17:52:12 UTC, mw wrote:
>On Thursday, 12 November 2020 at 13:16:21 UTC, Steven Schveighoffer wrote:
>On 11/12/20 4:22 AM, Per Nordlöw wrote:
>Why don't I get a stack trace on Memory allocation exceptions?
In my case I only get:
src/core/exception.d(647): [unittest] Memory allocation failed
core.exception.OutOfMemoryError@src/core/exception.d(647): Memory allocation failed
Certain errors are flagged as not able to allocate memory. So you don't get a stack trace.
I think it's a huge mistake, and we don't need memory allocation to do stack trace printing. But that's the way it is.
Hit this one today, since it's a mistake, what does it take to fix it? or you are saying it's unfix-able in the current D runtime?
It is fixable, but it'll take a lot of work. The main blocker is that the interface that is exposed to the user relies on memory allocation.
Namely, the TraceInfo
interface is: https://github.com/dlang/druntime/blob/2d8b28da39e8bc3bc3172c69bb96c35d77f40d2a/src/object.d#L2257-L2261
Note that:
toString
returns astring
(allocation);- The
opApply
's delegate use achar[]
as parameter;
What we should have is an opApply
on a struct that contains all necessary info, which itself writes to a sink / OutputRange.
Such struct exists (https://github.com/dlang/druntime/blob/a17bb23b418405e1ce8e4a317651039758013f39/src/core/internal/backtrace/dwarf.d#L77-L160) but need to be exposed to user code.
Then printing the stack trace will no longer allocate. However, defaultTraceHandler
still returns an object, so acquiring the handler will also need to be addressed. There have been talks of deprecating chained Exceptions, and that would make such a task much simpler.