[clug] gdb output
Duncan Roe duncan_roe at acslink.net.auMon 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 thereis no stack history available because the stack pointer is also zero.In general, there are only three ways to make the program counter do somethingother 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 above3 is return.So, you are looking for a function that wrote zeroes over its stack frame andthen tried to return, setting both the program counter and stack frame pointerto zero.The function that did the zeroising is not necessarily at fault: you can callmemset 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 "infothreads" will tell you. Anyway, you could try "n"ext through your toplevel untilyou find the function call containing the problem. Then breakpoint that functionand 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