Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault

Hello Tom,

04.03.2024 00:39, Tom Lane wrote:
> I wrote:
>> I find this in [1]:
>>
>> The C language stack growth does an implicit mremap. If you want absolute
>> guarantees and run close to the edge you MUST mmap your stack for the
>> largest size you think you will need. For typical stack usage this does
>> not matter much but it's a corner case if you really really care
>>
>> Seems like we need to do some more work at startup to enforce that
>> we have the amount of stack we think we do, if we're on Linux.
> After thinking about that some more, I'm really quite unenthused about
> trying to remap the stack for ourselves. It'd be both platform- and
> architecture-dependent, and I'm afraid it'd introduce as many failure
> modes as it removes. (Notably, I'm not sure we could guarantee
> there's a guard page below the stack.) Since we've not seen reports
> of this failure from the wild, I doubt it's worth the trouble.

I have perhaps a naive idea, but it apparently eliminates the segmentation
fault for the given test case. (Please look at a quick draft attached.)

Though maybe the issue can really wait for complaints from outside or for
a simpler/cheaper solution, integrated with the existing (or future)
stack-overflow protection.

> I do think it's probably worth reducing MemoryContextDelete's stack
> usage to O(1), just to ensure we can't get into stack trouble during
> transaction abort. That's not hard at all, as attached.

Yeah, Heikki proposed something similar as part of
0003-Avoid-recursion-in-MemoryContext-functions.patch there:
https://www.postgresql.org/message-id/6b48c746-9704-46dc-b9be-01fe4137c824%40iki.fi

> I tried to make MemoryContextResetChildren work similarly, but that
> doesn't work because if we're not removing child contexts then we
> need extra state to tell which ones we've done already. For the
> same reason my idea for bounding the stack space needed by
> MemoryContextStats doesn't seem to work. We could possibly make it
> work if we were willing to add a temporary-use pointer field to all
> MemoryContext headers, but I'm unconvinced that'd be a good tradeoff.

Best regards,
Alexander