Re: alloca is bad?

[Michael Meissner <meissner at cygnus dot com>]

On Sun, Nov 12, 2000 at 08:48:43PM +1100, Andrew Cagney wrote:
> Eli Zaretskii wrote:
> > 
> > > Date: Sat, 11 Nov 2000 19:51:36 +0000
> > > From: Fernando Nasser <fnasser@cygnus.com>
> > >
> > > Someone said that heap corruption was harder to track than stack
> > > corruption.
> > >
> > > I couldn't disagree more.  Many (most?) of the times the function tries
> > > to return and gets a buggy return address and frame pointer.
> > > It then crashes and you have no idea where it happened.
> 
> This is more in line with my personal experience.  Something gets
> trashed in the heap and it is a fairly well defined mechanical process
> to first script a reproducable sequence that triggers the event and
> secondly script a debug sequence that watches for the corruption. 
> Typically a few well placed watchpoints and a very long lunch (while it
> runs :-) does the trick.
> 
> On the other hand applying such a technique to a stack corruption is far
> more complicated.  The very nature of a stack is that it is constantly,
> and _annonymously_ being reused.  Typically far more complex tracing
> sequences are needed to capture the corruption in progress.

I tend to agree with Andrew and against Chris in this regard.  For malloc
overruns, I typically just link in with -lefence or other tools, and it is
fairly obvious where the bug is.  In the past, for particularly nasty stack
overruns, I have changed the compiler to emit special debug code for prologues
and epilogues (of course nowadays, you can use -finstrument-functions to
accomplish the same behavior).

-- 
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