Bug 514261
Summary: | gdb's stack traces not useful | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Lennart Poettering <lpoetter> |
Component: | gdb | Assignee: | Jan Kratochvil <jan.kratochvil> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | danw, dcantrell, jan.kratochvil, mtasaka, tbzatek |
Target Milestone: | --- | Keywords: | Reopened |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
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 08:07:51 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 473302 |
Description
Lennart Poettering
2009-07-28 15:41:18 UTC
prelink -au didn't make things any better. Seems to be unrelated to prelink 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. This doesn't really block the critical path for F12 alpha, so moving it off the blocker list. 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. 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. I don't know if this should be fixed before F12alpha or not, however recently I always see this problem like bug 514720 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 ?? () 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. 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 *** |