Bug #920

Incomplete backtrace in gdb

Added by hasso over 9 years ago. Updated over 9 years ago.

Target version:
Start date:
Due date:
% Done:



With current HEAD and gdb 6.7.1 I can't get complete backtraces any more.
Example from Xorg.core:

(gdb) bt
#0 0x283409c8 in kill () from /usr/lib/
#1 0x2838b04a in abort () from /usr/lib/
#2 0x08193de5 in FatalError ()
#3 0x080b4f15 in xf86SigHandler ()
#4 <signal handler called>
#5 0x081695e6 in XkbEnableDisableControls ()
#6 0x0816ab79 in XkbRemoveResourceClient ()
#7 0x0807b766 in ?? ()
#8 0x28618300 in ?? ()
#9 0x41a00000 in ?? ()
#10 0xbfbff2d8 in ?? ()
#11 0x0807b506 in ?? ()
#12 0xffffffff in ?? ()
#13 0x081a6625 in ?? ()
#14 0x28618300 in ?? ()
#15 0x081adfc4 in ?? ()
#16 0x28618400 in ?? ()
#17 0x081db5ec in xeviehot ()
#18 0xbfbff2f8 in ?? ()
#19 0x0807b9e4 in CloseDownDevices ()
Backtrace stopped: frame did not save the PC


#1 Updated by corecode over 9 years ago

could you supply the core and binary for debugging?


#2 Updated by corecode over 9 years ago

I received both from hasso privately.

I have to say that gdb is not really at fault here. Thorough
investigation revealed:

#7 0x0807b766 in ?? ()

This function really doesn't exist. Well, it does, but it doesn't have a
visible symbol. Because of this, gdb can't analyze the function prologue
and thus assumes that there is nothing on the stack - of course this is
wrong. We could change gdb to assume that there is always a stack frame
and this way it could work better for this case.

Previous gdb versions mistakenly assumed a different calling function and
happily unwound the prologue of the wrong function. This led to better
backtraces, but possibly wrong ones.


#3 Updated by dillon over 9 years ago

Also note that GCC-4 by default rolls up functions it thinks it
can inline on a file-by-file basis. So if function A calls function B
and GCC thinks it can inline function B in function A, whether or
not you've told it to, it will. You'll then get an error for function
B but the gdb backtrace will list the problem as being in function A.

I've noticed this when trying to debug kernels. I personally think
its a mistake, along with the idiotic default numeric optimizations
that break bounds checks.


#4 Updated by corecode over 9 years ago

yes, this is in so far annoying, because you can't properly "escape" from
the inlined part. also, debugging symbols sometimes don't seem to work

i don't think that it yields a big benefit, but makes debugging harder.
so i would rather not have it. maybe we should research on how to switch
this auto-inlining off.


#5 Updated by hasso over 9 years ago

Fixed in 1.12.2 and up.

Also available in: Atom PDF