Re: alloca is bad?

[Eli Zaretskii <eliz at delorie dot com>]

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

The same happens with overrunning malloc'ed buffers or free'ing the
same buffer twice: you get a corrupted chain of memory buffers in the
malloc-maintained pool of memory, and the program crashes at some
random point down the road, inside malloc or inside free.  The core
file contains no evidence about who corrupted the heap.  If you don't
have sources to malloc, you usually ned an malloc debugger to find the
villain.  However, many malloc debuggers increase the memory footprint
to such an extent that it becomes impractical to use them in large
programs which allocate and free memory all the time.

In contrast, with stack corruption, the crash is much more close to
the corruption point, usually a function call or two away, because the
stack is a single entity that gets exercised all the time, not
subdivided into buckets like in a typical malloc implementation.  It
is relatively easy to find the function which corrupted the stack,
e.g. by putting a watchpoint on the stack pointer register that
catches the moment when it is below the stack limit (assuming
expand-down stack).  Since registers can usually only be watched by
software watchpoints, knowing the approximate area where the offending
code should be is very important, otherwise running a program in
single-step can render this technique impractical.