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 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.