https://bugzilla.novell.com/show_bug.cgi?id=390722 User mmeeks@novell.com added comment https://bugzilla.novell.com/show_bug.cgi?id=390722#c22 --- Comment #22 from Michael Meeks <mmeeks@novell.com> 2008-05-20 02:11:05 MST --- As another data-point for "It's not going to work without that missing information", here is gdb doing really rather well having jumped a load of mangled stack frames to a frame where there is debuginfo: (gdb) bt #0 0x08048584 in ?? () #1 0x080486b0 in _IO_stdin_used () #2 0x00000001 in ?? () #3 0x00000025 in ?? () #4 0x40183560 in ?? () from /lib/libc.so.6 #5 0x00000027 in ?? () #6 0x401876c0 in ?? () #7 0xbff1ee18 in ?? () #8 0x080485b0 in ?? () #9 0x00000001 in ?? () #10 0x00000003 in ?? () #11 0xbff1ee38 in ?? () #12 0x4001e4ac in trace_two (fn=0x1) at two.c:8 Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) up 12 #12 0x4001e4ac in trace_two (fn=0x1) at two.c:8 8 fn (1, 3); (gdb) l 3 extern int trace_one (int a, unsigned int b); 4 5 void trace_two (int (*fn) (int, unsigned int)) 6 { 7 fprintf (stderr, "this method should have nice debuginfo\n"); 8 fn (1, 3); 9 } (gdb) Clearly examining (non-)frame #8 doesn't look so good: #8 0x080485b0 in ?? () (gdb) l Line number 10 out of range; two.c has 9 lines. but - that's expected of course. So: it seems that far from being hopeless without the missing information: if we can move into a valid frame higher up the stack that is associated with some debuginfo (and which can easily be determined from %ebp chaining): then we can in fact do some really rather useful debugging :-) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.