From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: Eli Zaretskii Cc: cgf@redhat.com, meissner@cygnus.com, gdb@sources.redhat.com, cagney@cygnus.com Subject: Re: alloca is bad? Date: Sun, 12 Nov 2000 15:16:00 -0000 Message-id: <3A0F24AA.50E22A01@cygnus.com> References: <20001109212032.A26464@redhat.com> <20001109213750.28987@cse.cygnus.com> <20001109222231.A26675@redhat.com> <3A0DA348.6BDDAFD4@cygnus.com> <200011120538.AAA01237@indy.delorie.com> <3A0E4F83.5F9D97FF@cygnus.com> <200011121216.HAA01483@indy.delorie.com> X-SW-Source: 2000-11/msg00110.html Eli Zaretskii wrote: > > > Date: Sun, 12 Nov 2000 08:06:27 +0000 > > From: Fernando Nasser > > > > 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 you are. As Andrew explained in his message, if the stack is corrupted the PC and FP can (and probably will) be clobbered with the garbage when the function returns. No backtrace, core dump or anything in this world will tell you where you were when this happens as all information has been obliterated. The GDB where command works by following the chain of stack frames by using the saved values of frame pointers (or equivalent mechanisms) to walk up the stack and give you that nice printout. Without a point to start, no chain can be recreated. Bottom line: for most stack corruption problems, no "where" ("backtrace") -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@redhat.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9