[Top][All Lists]
[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