Project

General

Profile

Bug #920

Incomplete backtrace in gdb

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

Status:
Closed
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%


Description

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/libc.so.6
#1 0x2838b04a in abort () from /usr/lib/libc.so.6
#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
(gdb)

History

#1 Updated by corecode almost 10 years ago

could you supply the core and binary for debugging?

thanks
simon

#2 Updated by corecode almost 10 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.

cheers
simon

#3 Updated by dillon almost 10 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.

-Matt

#4 Updated by corecode almost 10 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
correctly.

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.

cheers
simon

#5 Updated by hasso over 9 years ago

Fixed in 1.12.2 and up.

Also available in: Atom PDF