Missing stacktrace on memory allocation failure
Mathias LANG
geod24 at gmail.com
Thu Jun 3 00:06:52 UTC 2021
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 at 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:
1) `toString` returns a `string` (allocation);
2) The `opApply`'s delegate use a `char[]` 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.
More information about the Digitalmars-d-learn
mailing list