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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexander Lakhin <exclusion(at)gmail(dot)com>
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
Date: 2024-03-02 19:58:39
Message-ID: 3148162.1709409519@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

I wrote:
> 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 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.

regards, tom lane

[1] https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2024-03-03 21:39:29 Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault
Previous Message Tom Lane 2024-03-02 18:49:58 Re: BUG #18374: Printing memory contexts on OOM condition might lead to segmentation fault