bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-gnulib] Re: alloca


From: Bruno Haible
Subject: Re: [Bug-gnulib] Re: alloca
Date: Thu, 13 Nov 2003 22:17:22 +0100
User-agent: KMail/1.5

Paul Eggert wrote:
> But the issue here isn't valid alloca calls; it's the
> invalid ones with huge sizes (e.g. alloca (SIZE_MAX)).  For such
> calls, if you merely access a few bytes at the start of the newly
> "allocated" array (the base of which actually points into some other
> storage, used for some other purpose), you may not have a page fault
> at all, so expand_stack won't be called: but you'll still trash your
> program.  However, if you adopt the approach Youngman suggests, you'll
> eventually get a page fault due to a stack address that, if allocated,
> would cause the program to exceed RLIMIT_STACK or RLIMIT_AS limits, so
> the program will fail reliably.

I agree, James' suggested technique of filling arrays slowly would
reliably detect the stack overflow, whereas otherwise the program only
has a high probability of crashing a little later. (I just tried
  int main () { alloca(0x7fead000); printf("Hello world\n"); }
and it does crash inside printf().)

> It seems to me that the crucial issue here is the size of the
> unwriteable barrier just past the stack.  If the operating system
> guarantees that this barrier is always at least 8 KiB, for example,
> then any alloca of 8 KiB or less is "safe", in the sense that stack
> overflow will be detected reliably.

Linux 2.4 by default guarantees one page; this can be configured through
/proc/sys/vm/heap-stack-gap.

However, the objective of my suggestions about alloca() was not to
guarantee a crash when the program does something wrong, but rather
to maximize the probability that it does nothing wrong.

Bruno





reply via email to

[Prev in Thread] Current Thread [Next in Thread]