Mirror of the gdb mailing list
 help / color / mirror / Atom feed
[parent not found: <20001109222231.A26675@redhat.com>]
* alloca is bad?
@ 2000-11-09 18:20 Christopher Faylor
       [not found] ` <200011101039.FAA29788@indy.delorie.com>
  0 siblings, 1 reply; 5+ messages in thread
From: Christopher Faylor @ 2000-11-09 18:20 UTC (permalink / raw)
  To: gdb

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 <meissner@cygnus.com>
To: Christopher Faylor <cgf@redhat.com>
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 <cgf@redhat.com>
To: Michael Meissner <meissner@cygnus.com>
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 <nsd@redhat.com>
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 <qqi@world.std.com>
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: <Pine.SGI.3.95.1001110004316.25512C-100000@world.std.com>
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.







^ permalink raw reply	[flat|nested] 5+ messages in thread
end of thread, other threads:[~2000-11-11 13:16 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <3A0CE1DB.6F6B1E93@cygnus.com>
     [not found] ` <200011111713.eABHDrN15135@rtl.cygnus.com>
2000-11-11 11:37   ` alloca is bad? Fernando Nasser
2000-11-11 13:16     ` Nick Duffek
     [not found] <20001109222231.A26675@redhat.com>
     [not found] ` <200011100503.eAA53pT24667@rtl.cygnus.com>
2000-11-09 22:18   ` Andrew Cagney
2000-11-09 18:20 Christopher Faylor
     [not found] ` <200011101039.FAA29788@indy.delorie.com>
     [not found]   ` <20001110111651.A19503@redhat.com>
2000-11-10 21:34     ` Andrew Cagney

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox