Re: alloca is bad?

[Michael Meissner <meissner at cygnus dot com>]

On Sun, Nov 12, 2000 at 07:16:58AM -0500, Eli Zaretskii wrote:
> > Date: Sun, 12 Nov 2000 08:06:27 +0000
> > From: Fernando Nasser <fnasser@cygnus.com>
> > 
> > The problem is that with a corrupted SP and FP you have no idea of where
> > it happened.  Doesn't matter if the crash was immediately after the fact,
> > all evidence of when it happened is wiped away.
> 
> ??? The core file will usually tell you the function in which it
> crashed, and sometimes the one which called it (if you are lucky).
> GDB doesn't need the stack information to tell you what function
> crashed, the value of $pc should be enough.  At least usually.
> 
> Or am I missing something?

Yes, what usually happens is the return address that is saved on the stack is
corrupted (not necessarily the return address of the current function, but I've
seen corruption once or twice a couple of levels back).  When the function
whose return address is corrupted returns it jumps to the address.  If you are
somewhat lucky, the address is not a legal address and you get an immediate
core dump, though the pc is 0 or some such, which is totally useless, since on
most hardware, there isn't a come from address that says what was the pc before
the last jump.  If you aren't as lucky, it will jump to random code, and it may
be some time before you notice the corruption.

> > On the other hand, if you can get your execution path to repeat in a 
> > deterministic way so heap pieces are allocated in the same locations,
> > you can use hardware watchpoints (as it is memory, not registers).
> 
> This is usually almost impossible without having sources to malloc.
> Without the sources, you won't know where to put the watchpoints: all
> you have is the garbled pointer in the register which caused the
> crash, and the crash is usually not related to what your program did
> at the point of the crash, so your own variables don't help.

Or you can take one of the GPL mallocs and compile it on your system and link
it in.

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