From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eli Zaretskii To: fnasser@cygnus.com Cc: cgf@redhat.com, meissner@cygnus.com, gdb@sources.redhat.com, cagney@cygnus.com Subject: Re: alloca is bad? Date: Sat, 11 Nov 2000 21:39:00 -0000 Message-id: <200011120538.AAA01237@indy.delorie.com> References: <20001109212032.A26464@redhat.com> <20001109213750.28987@cse.cygnus.com> <20001109222231.A26675@redhat.com> <3A0DA348.6BDDAFD4@cygnus.com> X-SW-Source: 2000-11/msg00101.html > Date: Sat, 11 Nov 2000 19:51:36 +0000 > From: Fernando Nasser > > 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.