Bug 514261 - gdb's stack traces not useful
gdb's stack traces not useful
Status: CLOSED DUPLICATE of bug 516627
Product: Fedora
Classification: Fedora
Component: gdb (Show other bugs)
rawhide
All Linux
low Severity medium
: ---
: ---
Assigned To: Jan Kratochvil
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks: F12Target
  Show dependency treegraph
 
Reported: 2009-07-28 11:41 EDT by Lennart Poettering
Modified: 2013-01-10 00:18 EST (History)
5 users (show)

See Also:
Fixed In Version: gdb-6.8.50.20090803-2.fc12
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-08-11 04:07:51 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Lennart Poettering 2009-07-28 11:41:18 EDT
gdb is very confused in rawhide. Although all debuginfo packages are installed it is seldomly abale to even show a useful backtrace.

For example, currently I am debugging wnck-applet, and gdb decides to create this bt for me:

(gdb) bt
#0  0x00007fdc3b3288dd in pa_context_get_state (c=0x1ad62d0) at pulse/context.c:1042
#1  0x00007fdc3b56983b in pulse_driver_open (c=0x1a792a0) at pulse.c:375
#2  0x00007fdc3c2bfc52 in driver_open (c=0x1a792a0) at dso.c:266
#3  0x00007fdc3c2b74a8 in context_open_unlocked (c=0x1a792a0) at common.c:291
#4  0x0000000000004389 in ?? ()
#5  0x0000000001a55a90 in ?? ()
#6  0x0000000001a792a0 in ?? ()
#7  0x00007fdc3c2b7cb5 in ca_context_play_full (c=0x7fdc3c2b74a8, id=0, p=0x1a78e70, cb=0, userdata=0x0) at common.c:515
#8  0x00007fdc3c4c67a0 in ca_gtk_play_for_widget (w=0x1a9f000, id=0) at canberra-gtk.c:356
#9  0x00007fdc3c6cb4c8 in dispatch_sound_event (d=<value optimized out>) at canberra-gtk-module.c:394
#10 idle_cb (d=<value optimized out>) at canberra-gtk-module.c:643
#11 0x00007fdc3c6cb9fa in g_queue_pop_head () at gqueue.c:464
#12 0x00007fdc3c6cb9f0 in g_queue_pop_head () at gqueue.c:464
#13 0x0000000000000000 in ?? ()

There's a lot wrong here: some smybols (with weird addresses) are not resolved at all, g_queue_pop() does not actually call any other functions so should not show here up like this, and the bt ends a little bit to early. This is just one example, in many other cases the bts are even more useless.

This is with prelink enabled. I will now disable it and check if things become more useful then.
Comment 1 Lennart Poettering 2009-07-28 11:47:22 EDT
prelink -au didn't make things any better. Seems to be unrelated to prelink
Comment 2 Lennart Poettering 2009-07-28 11:48:55 EDT
for many of my threads gdb even shows a stack trace like this now:

#0  __pthread_mutex_lock_full (mutex=0xf5b660) at pthread_mutex_lock.c:303
#1  0x0000000000000002 in ?? ()
#2  0x00007fd6162afdc0 in ?? ()
#3  0x00007fd628e91380 in ?? () from /lib64/libpthread.so.0
#4  0x0000000000000000 in ?? ()

Which is completely useless.
Comment 3 Jesse Keating 2009-07-29 18:38:31 EDT
This doesn't really block the critical path for F12 alpha, so moving it off the blocker list.
Comment 4 Lennart Poettering 2009-07-29 21:24:24 EDT
Jesse, but what would the alpha be good for if we cannot even get useful stack traces from the bugs we find there? I mean, I am not sure what the alpha is intended to achieve, but if it is to get people to test and report bugs back we need to give them the tools along with it to do that in a way that doesn't just generate garbage.
Comment 5 Jesse Keating 2009-07-29 21:51:22 EDT
First thing you're going to ask them is to apply all the updates from rawhide, and then try it again.  And if it fails then, /then/ you get a backtrace with gdb, which by then has hopefully been fixed.
Comment 6 Mamoru TASAKA 2009-07-30 11:18:23 EDT
I don't know if this should be fixed before F12alpha or not,
however recently I always see this problem like bug 514720
Comment 7 Jan Kratochvil 2009-08-04 03:29:50 EDT
The new rebased GDB includes archer-tromey-call-frame-cfa from Tom Tromey so that DW_OP_call_frame_cfa used by new GCCs works now.

gdb-6.8.50.20090803-2.fc12.x86_64:
#0  _IO_fputs (str=0x612ec0 ".gnome2\t\t(Directory, x-directory/normal)\tsize 4096", fp=0x7ffff4dd0780) at iofputs.c:36
#1  0x00007ffff565f973 in g_print () from /lib64/libglib-2.0.so.0
#2  0x0000000000401d26 in show_data (directory=<value optimized out>, item=<value optimized out>) at gnomevfs-ls.c:93
#3  list (directory=<value optimized out>, item=<value optimized out>) at gnomevfs-ls.c:167
#4  0x00000000004020ab in main (argc=1, argv=0x7fffffffd5f8) at gnomevfs-ls.c:230

gdb-6.8.50.20090302-39.fc12.x86_64:
#0  *__GI__IO_fputs (str=0x612ec0 ".gnome2\t\t(Directory, x-directory/normal)\tsize 4096", fp=0x7ffff4dd0780) at iofputs.c:36
#1  0x00007ffff565f973 in g_print () from /lib64/libglib-2.0.so.0
#2  0x0000003000000030 in ?? ()
#3  0x00007fffffffd490 in ?? ()
#4  0x00007fffffffd3a0 in ?? ()
#5  0x0000000000606570 in ?? ()
#6  0x000000000060d1e0 in ?? ()
#7  0x0000000000611d20 in ?? ()
#8  0x00000000004022dd in __dso_handle ()
#9  0x00000000004022dd in __dso_handle ()
#10 0x00000000004022dd in __dso_handle ()
#11 0x00000000004023eb in __dso_handle ()
#12 0x0000000000000000 in ?? ()
Comment 8 Lennart Poettering 2009-08-10 21:17:27 EDT
Sorry. The stacktraces are a bit more useful now, but still don't work properly.

Just look at all the "can't compute CFA for this frame":

(gdb) bt
#0  on_seat_session_added_full (seat=can't compute CFA for this frame
) at ck-manager.c:1253
#1  0x00007ffff6c45b4e in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#2  0x00007ffff6c5bd06 in ?? () from /lib64/libgobject-2.0.so.0
#3  0x00007ffff6c5d12e in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#4  0x00007ffff6c5d6a3 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#5  0x000000000040f05e in ck_seat_add_session (seat=can't compute CFA for this frame
) at ck-seat.c:636
#6  0x0000000000409b13 in open_session_for_leader (manager=can't compute CFA for this frame
) at ck-manager.c:1629
#7  0x0000000000409ba4 in verify_and_open_session_for_leader (manager=can't compute CFA for this frame
) at ck-manager.c:1651
#8  0x0000000000409c26 in collect_parameters_cb (leader=can't compute CFA for this frame
) at ck-manager.c:1673
#9  0x0000000000411a1c in job_completed (job=can't compute CFA for this frame
) at ck-session-leader.c:390
#10 0x00007ffff6c45b4e in g_closure_invoke () from /lib64/libgobject-2.0.so.0
#11 0x00007ffff6c5bd06 in ?? () from /lib64/libgobject-2.0.so.0
#12 0x00007ffff6c5d12e in g_signal_emit_valist () from /lib64/libgobject-2.0.so.0
#13 0x00007ffff6c5d6a3 in g_signal_emit () from /lib64/libgobject-2.0.so.0
#14 0x000000000040d493 in maybe_complete_job (job=can't compute CFA for this frame
) at ck-job.c:120
#15 0x000000000040d6d6 in out_watch (source=can't compute CFA for this frame
) at ck-job.c:206
#16 0x00007ffff678a1be in g_main_context_dispatch () from /lib64/libglib-2.0.so.0
#17 0x00007ffff678dba8 in ?? () from /lib64/libglib-2.0.so.0
#18 0x00007ffff678dff5 in g_main_loop_run () from /lib64/libglib-2.0.so.0
#19 0x0000000000406b94 in main (argc=can't compute CFA for this frame
) at main.c:334
(gdb) 

And "bt full" stops at the first stack frame already:

(gdb) bt full
#0  on_seat_session_added_full (seat=can't compute CFA for this frame
) at ck-manager.c:1250
        ssid = can't compute CFA for this frame
(gdb) 

This is an -O0 -g build. All library debug symbols enabled.
Comment 9 Jan Kratochvil 2009-08-11 04:07:51 EDT
It is now addressed by Tom Tromey in a different RH Bug, thanks for the reopen.

*** This bug has been marked as a duplicate of bug 516627 ***

Note You need to log in before you can comment on or make changes to this bug.