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

Alexander Lakhin <exclusion(at)gmail(dot)com> writes:
> 02.03.2024 19:11, Tom Lane wrote:
>> Hmph. That's not an out-of-memory crash, that's a stack-too-deep
>> crash.

> (gdb) p $rsp
> $1 = (void *) 0x7ffcc83d4ff0
> (gdb) frame 13269
> #13269 0x000056289bc2685a in main (argc=8, argv=0x56289d3b4930) at main.c:198
> 198                     PostmasterMain(argc, argv);
> (gdb) p $rsp
> $2 = (void *) 0x7ffcc84834d0
> (gdb) p $rsp - 0x7ffcc83d4ff0
> $3 = (void *) 0xae4e0

> (Far less than ulimit -s == 8 MB.)

Yeah, I'm seeing something similar, also with ulimit -s = 8192 kbytes:

(gdb) i reg
...
rbp 0xb0a324 0xb0a324
rsp 0x7ffd07ce4fd0 0x7ffd07ce4fd0
...
(gdb) x/64 0x7ffd07ce4fd0
0x7ffd07ce4fd0: Cannot access memory at address 0x7ffd07ce4fd0

So it's definitely out-of-stack, yet

(gdb) p stack_base_ptr
$3 = 0x7ffd07dbf570 "\b"
(gdb) p 0x7ffd07dbf570 - 0x7ffd07ce4fd0
$4 = 894368

I'd have expected a diff in the vicinity of 8MB, but it isn't.

I think what must be happening is that the kernel is refusing
to expand our stack any more once we've hit the "ulimit -v" limit.
This is quite nasty, because it breaks all our assumptions about
having X amount of stack still available once check_stack_depth
triggers.

I tried inserting check_stack_depth() into MemoryContextStatsInternal,
and *that did not stop the crash*, confirming that we don't think
we're anywhere near the stack limit. Ugh.

regards, tom lane