Re: alloca is bad?

[Fernando Nasser <fnasser at cygnus dot com>]

Eli Zaretskii wrote:
> 
> (...)
> 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,

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.


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

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


-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9