gdb is in a very bad state. Useless for any debugging. Even if I run an app that I know has zillions of threads "info threads" will still try to convince me it has a zero threads. (not even one!) I cannot switch the active thread. When I attach to a running process with lots of threads gdb will only stop a single thread, leave the others running and then get very confused by that. gdb segfaults all the time. In short: gdb is completely useless right now.
As a workaround you may install glibc-debuginfo (I did not see this problem). The problem is that /lib64/libpthread-2.8.90.so is now more stripped and it has no longer the _thread_db_* symbols required by libthread_db to support threads. Regarding GDB in general I use kernel-2.6.25.10-86.fc9.x86_64 as any later kernel has showstopper ptrace/utrace problems (currently remains the Bug 468089).
glibc-2.8.90-14.x86_64
Indeed, "info threads" works after installing those debug symbols for glibc, Segfaults and borkage isn't fixed though. I tried to track down bug 467651 a bit. No luck, gdb fails right-aways when opreport segfaults. A debugger that crashes when the debugged program crashes is pretty pointless, isn't it? 49 [lennart@lambda] ~$ gdb --args opreport -l /home/lennart/projects/pulseaudio/src/.libs/lt-pulseaudio GNU gdb Fedora (6.8-24.fc10) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (gdb) r Starting program: /usr/bin/opreport -l /home/lennart/projects/pulseaudio/src/.libs/lt-pulseaudio warning: [vdso] (tgid:30206 range:0x110000-0x111000) could not be found. warning: [vdso] (tgid:32384 range:0x110000-0x111000) could not be found. warning: [vdso] (tgid:32553 range:0x110000-0x111000) could not be found. warning: [vdso] (tgid:5805 range:0x110000-0x111000) could not be found. CPU: Core Solo / Duo, speed 1000 MHz (estimated) Counted CPU_CLK_UNHALTED events (Unhalted clock cycles) with a unit mask of 0x00 (Unhalted core cycles) count 100000 ../../gdb/buildsym.c:1281: internal-error: buildsym_init: Assertion `! pending_addrmap' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) y ../../gdb/buildsym.c:1281: internal-error: buildsym_init: Assertion `! pending_addrmap' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Create a core file of GDB? (y or n) y Aborted 50 [lennart@lambda] ~$
Here you go: http://0pointer.de/public/core.20500.gz I sent gdb a SIGSEGV when the first question was asked to generate this dump. gdb-6.8-24.fc10.i386
Please move the GDB problem to the new Bug 468266 (I forgot to Cc you, sorry). This Bug is assigned for the glibc problem you already workarounded.
I don't believe we would block the release of F10 for this issue. Moving to Target.
The problem is on the rpm-build or file side. glibc.spec runs /usr/lib/rpm/find-debuginfo.sh --strict-build-id -g -o debuginfo.filelist and that should mean eu-strip -g -f is used rather than eu-strip -f, i.e. .symtab/.strtab sections should be kept in glibc shared libraries. But as can be seen in the debugging stuff I've tried in a scratch build, this doesn't work: http://koji.fedoraproject.org/koji/getfile?taskID=910550&name=build.log strip_g=true is clearly set, but then: + case "$(file -bi "$2")" in ++ file -bi /builddir/build/BUILDROOT/glibc-2.8.90-15.0.0.1.x86_64/lib6 /libpthread-2.8.90.so + eu-strip --remove-comment -f /builddir/build/BUILDROOT/glibc-2.8.90-15.0.0.1.x86_64/usr/lib/debug/lib64/libpthread-2.8.90.so.debug /builddir/build/BUILDROOT/glibc-2.8.90-15.0.0.1.x86_64/lib64/libpthread-2.8.90.so This corresponds to: strip_to_debug() { local g= $strip_g && case "$(file -bi "$2")" in application/x-sharedlib,*) g=-g ;; esac eu-strip --remove-comment $g -f "$1" "$2" || exit } in /usr/lib/rpm/find-debuginfo.sh. I've also added an explicit file -bi invocation to see the output on stdout: + file -bi /builddir/build/BUILDROOT/glibc-2.8.90-15.0.0.1.x86_64/lib64/libpthread-2.8.90.so application/x-sharedlib While F9 and earlier file(1) reported something like: application/x-sharedlib, for GNU/Linux 2.6.9, not stripped F10 apparently reports just application/x-sharedlib If the file(1) output change was intentional, then rpm-build should be fixed by removing the , from the pattern. @@ -90,7 +90,7 @@ strip_to_debug() { local g= $strip_g && case "$(file -bi "$2")" in - application/x-sharedlib,*) g=-g ;; + application/x-sharedlib*) g=-g ;; esac eu-strip --remove-comment $g -f "$1" "$2" || exit }
The fix from comment #7 built into rpm-4.6.0-0.rc1.7 and request for tagging into f10 filed: https://fedorahosted.org/rel-eng/ticket/931
Fixed as of rpm 4.6.0-0.rc1.7 and glibc 2.8.90-16