This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: alloca and reliable stack-overflow detection in glibc functions

> First, glibc's __libc_use_alloca seems to be designed for this
> problem, but it is not used uniformly in glibc.  For example, it's not
> used by sysdeps/generic/setenv.c, even though setenv uses alloca (N)
> for arbitrarily-large values of N.  Can I assume that this sort of
> problem is inadvertent, and that functions like setenv should be
> modified to use __libc_use_alloca?

Probably so.

> Second, __MAX_ALLOCA_CUTOFF is 64 * 1024, so __libc_use_alloca
> currently allows alloca (N) if N is less than 64 KiB.  Howerver, my
> understanding from Bruno Haible is that in some versions of Linux one
> can use /proc/sys/vm/heap-stack-gap to set the gap between the stack
> and heap to values as small as 4 KiB, which suggests that
> __MAX_ALLOCA_CUTOFF should be 4 KiB.  Am I misunderstanding the intent
> of __MAX_ALLOCA_CUTOFF?  (For all I know /proc/sys/vm/heap-stack-gap
> can be set to zero, in which case no gap would suffice.)

You can make the size arbitrarily small with the rlimit.  glibc does not
support arbtirarily small stack sizes.  I'm not sure we've specified what
the reasonable minimum is, but it's more 64k obviously.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]