Alexander Lakhin <exclusion@gmail.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
