From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Faylor To: Michael Meissner Cc: gdb@sources.redhat.com Subject: Re: alloca is bad? Date: Thu, 09 Nov 2000 19:22:00 -0000 Message-id: <20001109222231.A26675@redhat.com> References: <20001109212032.A26464@redhat.com> <20001109213750.28987@cse.cygnus.com> X-SW-Source: 2000-11/msg00055.html 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