There is a rather nasty crash possible in PHP due to the usage of the alloca()
function as can be demonstrated by bug #28064.
Simpler bug replication case:
php -r ' $a = str_repeat("a", 1024 * 1024 * 6); defined($a); '
The problem is the result of missing checks to determine if alloca() had
worked or not. The problem is further compounded by the fact that alloca() is
a dangerous function that will not always return NULL on failure, making the
return value check unreliable (read alloca manpage excerpt below).
In PHP4 this function is only used about 7 times, while PHP5 uses it a little
more frequently about 38 times. I think it would be best if do_alloca was
made to use emalloc that can safely handle allocation failures.
Alloca() is already an emalloc wrapper on Apple, HPUX, Windows, Netware.
Excerpt from alloca manpage:
NOTES ON THE GNU VERSION
Normally, gcc translates calls to alloca by inlined code. This is not
done when either the -ansi or the -fno-builtin option is given. But
beware! By default the glibc version of <stdlib.h> includes
<alloca.h> and that contains the line # define alloca(size)
__builtin_alloca (size) with messy consequences if one has a private version
of this function.
The fact that the code is inlined, means that it is impossible to take
the address of this function, or to change its behaviour by linking with a
different library.
The inlined code often consists of a single instruction adjusting the
stack pointer, and does not check for stack overflow. Thus, there is no NULL
error return.
BUGS
The alloca function is machine and compiler dependent. On many systems
its implementation is buggy. Its use is discouraged.
On many systems alloca cannot be used inside the list of arguments
of a function call, because the stack space reserved by alloca would appear
on the stack in the middle of the space for the function arguments
Ilia
Ilia Alshanetsky wrote:
There is a rather nasty crash possible in PHP due to the usage of the alloca()
function as can be demonstrated by bug #28064.
Simpler bug replication case:
php -r ' $a = str_repeat("a", 1024 * 1024 * 6); defined($a); '
The following two fragments will lead to virtually identical code:
void foo()
{
char bar[2048];
...
}
and
void foo()
{
char *bar = alloca(2048);
....
They both start out by moving the stack pointer down 2k to leave enough
room for bar, and they will both crash in a similar way if the stack
doesn't have enough room available.
I think that not alloca() itself but its improper use is the problem
here. Any function will cause a crash if you call it when your stack is
full. Just be sensible about when (not to) use it.
--
Ard
Virtually all current uses involve some form of user input, which means that
the user can exploit the problem. When bar[2048] is used to create a buffer
of a certain known size that never change, with alloca a buffer of undermined
size is created in most cases.
The only 'safe' way to use the function would be to put it inside a wrapper
that would check the size against some preset limit and based on that
determine if alloca or emalloc should be used. The length would also need to
be stored to allow the free wrapper to determine if efree() is needed. These
safety checks may offset the miniscule speed advantage gained by using alloca
anyway, especially when the length is being calculated inside alloca call.
Ilia
Virtually all current uses involve some form of user input, which means that
the user can exploit the problem. When bar[2048] is used to create a buffer
of a certain known size that never change, with alloca a buffer of undermined
size is created in most cases.The only 'safe' way to use the function would be to put it inside a wrapper
that would check the size against some preset limit and based on that
determine if alloca or emalloc should be used. The length would also need to
be stored to allow the free wrapper to determine if efree() is needed. These
safety checks may offset the miniscule speed advantage gained by using alloca
anyway, especially when the length is being calculated inside alloca call.
Calling malloc is generally not that expensive as you would hope that
the operating system would give you reasonable locality in the cases
where i've seen alloca() used. Doing a stack size check is still
dangerous, simply because you don't know what has been previously
allocated off the stack, nor do you know what will be allocated off
the stack further down within the function.
Calling do_alloca() to avoid a heap access is a bottom drawer
optimization, and yields very little when it comes to improving php's
memory usage patterns (as opposed to a fix block allocator)... ie, i
agree with ilia - it should just be hosed.
-sterling