From mboxrd@z Thu Jan 1 00:00:00 1970 From: Christopher Faylor To: gdb@sources.redhat.com Subject: alloca is bad? Date: Thu, 09 Nov 2000 18:20:00 -0000 Message-id: <20001109212032.A26464@redhat.com> X-SW-Source: 2000-11/msg00053.html 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... cgf >From meissner@cygnus.com Thu Nov 09 18:37:00 2000 From: Michael Meissner To: Christopher Faylor Cc: gdb@sources.redhat.com Subject: Re: alloca is bad? Date: Thu, 09 Nov 2000 18:37:00 -0000 Message-id: <20001109213750.28987@cse.cygnus.com> References: <20001109212032.A26464@redhat.com> X-SW-Source: 2000-11/msg00054.html Content-length: 2735 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. 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. 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. 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. -- Michael Meissner, Red Hat, Inc. PMB 198, 174 Littleton Road #3, Westford, Massachusetts 01886, USA Work: meissner@redhat.com phone: +1 978-486-9304 Non-work: meissner@spectacle-pond.org fax: +1 978-692-4482 >From cgf@redhat.com Thu Nov 09 19:22:00 2000 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 Content-length: 5779 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 >From nsd@redhat.com Thu Nov 09 20:57:00 2000 From: Nick Duffek To: gdb@sources.redhat.com Subject: Re: alloca is bad? Date: Thu, 09 Nov 2000 20:57:00 -0000 Message-id: <200011100503.eAA53pT24667@rtl.cygnus.com> References: <20001109222231.A26675@redhat.com> X-SW-Source: 2000-11/msg00056.html Content-length: 758 On 9-Nov-2000, Christopher Faylor wrote: >I've been told in private email that I mustn't use alloca Say it ain't so! >Alloca is useful. Especially because multi-arching is turning small compile-time constants into run-time variables all over the place. If we can't use alloca, then wherever there's something like this: char rawbuf[MAX_REGISTER_SIZE]; we'll have to convert it to this: char *rawbuf; ... rawbuf = malloc (MAX_REGISTER_SIZE); and do one of two things: 1. Perform the usual painful cleanup-chain surgery. 2. Carefully analyze the function and its entire call subtree to make sure non-local returns are impossible. Either way, we're in for a lot more complexity -- and therefore bugs -- than if we use alloca. Nick >From qqi@world.std.com Thu Nov 09 21:58:00 2000 From: Quality Quorum To: rtems-snapshots@oarcorp.com, gdb@sourceware.cygnus.com Cc: rtems-users@oarcorp.com Subject: i386_stub with thread support Date: Thu, 09 Nov 2000 21:58:00 -0000 Message-id: X-SW-Source: 2000-11/msg00057.html Content-length: 3304 Hi, I had just put i386_stub with thread support and remote.c replacement for gdb-4.18 here: ftp://www.std.com/Newbury/qqi/i386_stub.tar.gz . README is appended to this mail. Latest version of protocol document is in its usual place ftp://www.std.com/Newbury/qqi/protocol.txt . Web access is from my home page at http://www.std.com/qqi . Let me know what do you think. Thanks, Aleksey =========================== README ================================== Files in this directory provide remote gdb debugging with thread support for all RTEMS i386 BSPs. All 386-xxx files here are given to public domain, so they could be used as samples for other applications. The most important files (i386-stub.c and remote-4.18.c) are not RTEMS specific. General information about RTEMS is available at http://www.rtems.com . Current status is reasonable alpha. It seems to me that there are number of quirks in gdb core which has to be cleaned out (I suspect some of them are introduced by RTEMS specific patches), before this thing will be really usable. Files of interest in the current directory: GDB.HOWTO - how to enable gdb support for a RTEMS application README - this file protocol-1.3.txt - protocol description i386-stub-glue.c - RTEMS-specific glue between i386-stub and RTOS. i386-stub.c - stub itself i386-stub.h - definitions of stub-2-glue interface remote-4.18.c - drop in replacement for gdb-4.18/gdb/remote.c uart.c - RTEMS-specific 16552 driver, it is very generic (except for termios support section). The gdb support section is of particular interest - it allows to break into debugger by sending ^C uart.h - uart definitions A. RTEMS Notes This is a replacement for c/src/lib/libbsp/i386/shared/comm 1. File remote-4.18.c contains a replacement for gdb-4.18/gdb/remote.c. 2. There is no point in changing regsiters of any thread beyond stopped one - switched off thread is deep down into thread switching procedure, so there is no point of changin anything there. If one would like to debug thread switching - do not enable thread support in the debugger 3. Prototype void i386_stub_glue_init_with_threads(int uart) should be added to corresponding bsp.h B. Notes about remote-4.18.c The goal was a clean implementation of the protocol: o Various enhancements (like cisco mode) were eliminated. o All optional facilities (e.g. thread support, qOffsets etc) converted into regular format of `features'. New command `remotefeature' allows to mange/display status of various features. o Another essential change was folding extended-remote target into extended ops feature of remote-target. o New command `threadinfotest' is used to test qP requests, it displays quite useful information. o The simple and consisten way of collecting lists of threads was implemented. o The most signficant bug in original code (I suspect it is still true in gdb-5.0): (1) target_ops.to_has_thread_control has to be set to `tc_none', by the time objfile_relocate() is called gdb thinks that all current offsets are 0s and hence performce relocation out to nowhere.