[clug] gdb output

Duncan Roe duncan_roe at acslink.net.au Mon Mar 8 04:15:56 GMT 2004

Previous message: [clug] gdb output

Next message: [clug] PCI 2.2 devices and a non-PCI 2.2 bus

Messages sorted by:[ date ][ thread ][ subject ][ author ]

Hi Jim,

Gdb is telling you that the thread is executing at location zero, and that there
is no stack history available because the stack pointer is also zero.

In general, there are only three ways to make the program counter do something
other than move on to the next instruction in sequence: jump, call, and return.

With the displayed symptoms, I would say the most likely candidate of the above
3 is return.

So, you are looking for a function that wrote zeroes over its stack frame and
then tried to return, setting both the program counter and stack frame pointer
to zero.

The function that did the zeroising is not necessarily at fault: you can call
memset to produce the exact scenario for instance:-

 int main(int argc,char**argv)
 {
   int i;
   memset(&i,0,16);
   return 0;
 }

will fail when run under gdb:-

 Program received signal SIGSEGV, Segmentation fault.
 0x00000000 in ?? ()
 (gdb) bt
 #0  0x00000000 in ?? ()
 (gdb)

It wrote 12 bytes beyond the end of "i" and zapped the stack.

I suspect thread 16384 is your initial thread (but I'm not sure). Perhaps "info
threads" will tell you. Anyway, you could try "n"ext through your toplevel until
you find the function call containing the problem. Then breakpoint that function
and repeat the process.

Or maybe if you just audit you memset calls you'll find the problem.

Cheers ... Duncan.

On Fri, Mar 05, 2004 at 08:44:09PM +1100, Jim Watson wrote:
> how would i interpret this output from gdb?
> m received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 16384 (LWP 17669)]
> 0x00000000 in ?? ()
> (gdb) where
> #0  0x00000000 in ?? ()
> (gdb)
>
> jim

原文住所:http://blog.csdn.net/changingivan/article/details/7055013