Re: Preventing stack-overflow crashes (improving on max_expr_depth)

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Preventing stack-overflow crashes (improving on max_expr_depth)
Date: 2003-12-31 02:42:38
Message-ID: 200312310242.hBV2gcD26007@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Sounds like a great approach to me. If it doesn't work, we will find
out during beta testing.

---------------------------------------------------------------------------

Tom Lane wrote:
> We've had a couple of complaints in the past about recursive functions
> crashing the server by overflowing the C execution stack. There is a
> GUC variable max_expr_depth that is intended to prevent this sort of
> problem for the particular case of overly complex arithmetic
> expressions, but it's difficult to apply a similar solution to function
> calls. A function nesting depth limit would necessarily be pretty
> arbitrary, since different functions might use very different amounts of
> stack space.
>
> It occurred to me today that it would not be difficult to implement a
> direct check on the physical size of the execution stack. We could have
> PostgresMain do this:
>
> /* global variables: */
> char *stack_base_ptr;
> int max_stack_size; /* settable through GUC */
>
> PostgresMain(...)
> {
> char stack_base_loc;
>
> stack_base_ptr = &stack_base_loc;
>
> ... server main loop here ...
> }
>
> Then, in key recursive routines such as ExecQual, add a stack depth test
> that looks like
>
> void check_stack_depth(void)
> {
> char stack_top_loc;
>
> if (abs(stack_base_ptr - &stack_top_loc) > max_stack_size)
> elog(ERROR, "Stack depth limit exceeded");
> }
>
> Essentially we're measuring the distance between the local variables of
> PostgresMain and those of the current recursive routine. (The abs()
> operation is needed since the stack grows up on some machines and down
> on others.)
>
> Now, instead of a max_expr_depth variable that no one really knows how
> to set intelligently, we have a max_stack_size variable that we can tell
> people exactly how to set: a megabyte or so less than your "ulimit -s"
> value should work fine for most cases. And it works for everything;
> recursive function calls, whatever.
>
> I imagine that somewhere in the fine print of the ANSI C standard, it
> says that this maneuver doesn't give well-defined results --- but I
> cannot think of any platform where it wouldn't work.
>
> Comments?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
> (send "unregister YourEmailAddressHere" to majordomo(at)postgresql(dot)org)
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bret Busby 2003-12-31 02:49:38 Re: Is my MySQL Gaining ?
Previous Message Bruce Momjian 2003-12-31 02:40:41 Re: [PATCHES] Quoting of psql \d output