Re: alloca is bad?

[Christopher Faylor <cgf at redhat dot com>]

On Thu, Nov 09, 2000 at 09:37:50PM -0500, Michael Meissner wrote:
>On Thu, Nov 09, 2000 at 09:20:32PM -0500, Christopher Faylor wrote:
>>A patch that I recently submitted to gdb-patches used the alloca ()
>>function to allocate memory.  I've been told in private email that I
>>mustn't use alloca because "stack corruption problems are harder to
>>debug" than heap corruption problems.
>>
>>I was surprised by this assertion and so I thought I'd ask for a
>>consensus here.  Should the use of alloca be deprecated in gdb?
>>
>>It is my assertion that the amount of bookkeeping and overhead required
>>to use malloc in a way that is analogous with alloca essentially
>>nullifies the "harder to debug" argument.  malloc requires a free and
>>many times, in gdb context, the only way to guarantee a free is with
>>the use of the cleanup function.  Any time you add the complexity of
>>something like 'cleanup()' (or whatever other mechanism you use to
>>ensure that what you malloc is automatically freed) you can't claim to
>>have reduced debugging problems.  Speaking of free, with alloca you
>>don't have memory leaks.  With malloc, you do.
>>
>>If alloca is bad, then why are local arrays and pointers to local
>>variables and parameters ok?
>>
>>Inquiring minds...
>
>It depends on many things.  For any allocation that might involve a large
>number of items (say more than a page worth), it is better to use malloc than
>alloca.  This is due to a couple of factors:
>
>   1)	Stack space is usually more limited than data space.  On some systems
>	(ie, Windows), this is set at link time, while on others it can be set
>	by the parent shell (though usually the parent can't set the limit
>	higher than it's limit).  By the way, this affects large auto arrays
>	with static bounds as well.

I should have made the context clearer.  I am not advocating that alloca
replace malloc or that malloc is useless.  I understand (and hopefully
everyon who uses alloca understands) that you should not allocate 16MB
of information using alloca any more than you should have a 16M local
array.

>   2)	There is no error return value for alloca, so you can't have a more
>	friendly exit, instead the heap just gets corrupted.  The compiler just
>	allocates extra memory and assumes the stack is big enough.

This is probably a valid concern but it doesn't mean that you eliminate the
use of alloca.  It means that you use it responsibly.  Again, auto arrays
would suffer from the same problem.

>   3)	Large allocations of more than a page might confuse the OS's method of
>	growing the stack, which expects to be done via a function prologue.

You probably know more about this than I, however I there are something
like 2900 occurrences of the word 'alloca' in gcc.  I see alloca() used
to allocate space for path names and it is used in other places where
the length it is passed is not obviously checked for violation of the
page size.  So, if this is an issue then gcc must not work too well on
these OSes.

>   4)	There are 3rd party tools to check for pointers being out of bounds for
>	malloc requests like electric fence that you can plug in to get the
>	checking.
>
>The FSF GCC maintainers have gone through and tried to eliminate all allocas of
>any based off of the number of pseudo registers, basic blocks, or other
>variable things, and certainly seems to reduce the number of people complaining
>that their Windows compiler just died without warning.

The fact that there are debugging tools like Purify or Electric Fence
doesn't really seem like an argument to me.  To some degree, these tools
exist exactly because of the problems with the malloc/free paradigm.
You don't have memory leaks with alloca so you don't need a special tool
to track down memory leaks.

You can, of course, have array overruns with an alloca'ed buffer just
like you can with a malloced array.  In my experience, tracking down
stack corruption is usually a relatively trivial exercise essentially
involving a binary search.  With heap corruption the problems don't
necessarily manifest in a deterministic way.  A buffer overrun in
function x may cause a problem in function q even though function q is
not part of function x's call tree.  So, problems with heap corruption
are much less bounded.

Hmm.  I think that Purify actually does help track down stack corruption
so there is at least one tool for this.  I've never used Electric Fence
but I would be surprised if it was completely trivial to use and I would
be equally surprised if linking with Electric Fence automatically
pinpointed heap problems in every case.  In my experience with debugging
mallocs, adding them to the equation sometimes changes everything since
the allocation schemes are usually different from the system malloc that
is commonly used when linking applications.  So, using debugging mallocs
can actually mask or alter how the heap problem manifests.

However, even if it was the case that debugging problems with alloca was
more problematic than debugging heap problems, I don't think that this
is a compelling argument for not using alloca.  The added complexity
required to get malloc/free to do what alloca does naturally, coupled
with the added overhead required for managing the heap are two factors
that weigh against using malloc for everything IMO.

And, again, I can't think of any argument against using alloca that
doesn't also apply to automatic arrays.  If we are going to stop
using alloca then we should stop allocating automatic arrays, too.

I am not advocating replacing every malloc in gdb with alloca.  I'm just
lobbying against the "throwing out the baby with the bath water"
approach.  Alloca is useful.  IMO, its use should not be automatically
prohibited in all future gdb submissions.

cgf