Re: Should we add a compiler warning for large stack frames?

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org, Robert Haas <robertmhaas@gmail.com>, Thomas Munro <thomas.munro@gmail.com>
Date: 2024-04-12T00:56:54Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2024-04-11 16:35:58 -0400, Tom Lane wrote:
>> Indeed.  I recall reading, not long ago, some Linux kernel docs to the
>> effect that automatic stack growth is triggered by a reference into
>> the page just below what is currently mapped as your stack, and
>> therefore allocating a stack frame greater than one page has the
>> potential to cause SIGSEGV rather than the desired stack extension.

> I think it's more than a single page, but I'm not entirely sure either. I
> think some compilers inject artificial stack accesses when extending the stack
> by a lot, but I don't remember the details.

Hmm.  You're right that I was misremembering the typical RAM page
size.  The kernel must be allowing stack frames bigger than 4K,
or we'd see problems everywhere.  I wonder how much bigger ...

> frame size      warnings
> 4096            155
> 8192            111
> 16384           36
> 32768           14
> 65536           8

> Suggests that starting somewhere around 16-32k might be reasonable?

I'm hesitant to touch more than a handful of places on the strength
of the info we've got; either it's wasted work or it's not enough
work, and we don't know which.  Might be time for some
experimentation.

			regards, tom lane



Commits

  1. Don't allocate large buffer on the stack in pg_verifybackup