Red Hat Bugzilla – Bug 9373
gdb can hang loading shared libraries
Last modified: 2008-05-01 11:37:54 EDT
After upgrading from Redhat 6.1 (with gdb-4.18-4), I ran into a problem loading shared libraries in gdb using the "sharedlibrary" command. For whatever reason, certain libraries seem to just hang gdb. It just sits there (I've let it go for about 7 minutes), and consumes quite a bit of CPU time, but never seems to finish loading the symbols. It's not using abnormal amounts of memory, either, so this could be some sort of infinite looping. Ctrl-C does not interrupt gdb when it's in this state, you have to kill it from another terminal. The library I'm seeing this on in particular is libraptorhtml.so from Mozilla. This *could* be due to the library's large size (27 MB). Since this makes debugging pretty much impossible, this problem needs to be addressed before 6.2 release. I can provide this library for testing if necessary. Running on AMD K6-2/400, 128 MB RAM, 120 MB swap.
Confirmed. I see this behavoir as well.
Jim, any insights into this one?
Please see these urls for more information about this bug: http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00313.html http://sourceware.cygnus.com/ml/gdb/2000-q1/msg00329.html I ported Tom Tromey's symbol hash patch and it's an order of magnitude better. Unfortunately, it breaks debugging mozilla, or at least makes a known problem much worse. Basically, it's causing pthread_mutex_unlock() calls to crash. It might be a debugger, glibc or Mozilla problem. I've yet to build a brute force test case to see if I can break threads in gdb. I've got Tom's patch on my laptop. If anyone wants the patch I can add it to the bug. I've also got Jim's dlclose() patch built in which makes a good bit of difference and I've started to see the goodness of those changes. I've also got the .spec file changes.
please submit patches
In my opinion this is neither critical functionality, security, or embarrassing, if you are talking in terms of 6.2. Of course feel free to make your own call on that. In either case the real issue is getting it into CVS. I'm trying to break through the denial of the GDB maintainers (of which I'm not even one, yet) but until that is done I don't have a better suggestion than sending an inquiry to gdb-patches every few weeks asking for the status (well, for the Tromey patch, my dlclose patch needs at least one fix before being checked in).
Created attachment 122 [details] tom tromey's patch for hashing the symbol table
I've attached an updated version of Tom Tromey's patch for hashing the symbol tables. However, applying this patch makes another bug that Jim has reported in the past really, really bad: http://sourceware.cygnus.com/ml/bug-gdb/1999-10/msg00058.html While Tom Tromey's patch makes symbol loading an order of mangnitude faster it makes the SIGTRAP problem a show stopper. I've gotten the problem to show up on the -10 that we've got in the tree for 6.2 but it's really bad with the version that I have locally. It might be because the really fast symbol loading makes the race condition more likely to show up or something. The nice thing about the SIGTRAP problem showing up easier is that I now have a reproducable test case. I'm going to open a new bugzilla bug about the SIGTRAP issue since it's technically a different problem. Please keep in mind that I can't use gdb in 6.2 right now to do mozilla development at all because of this. I'm completely dead in the water and so is anyone who is using 6.2.
assign to jakub
This has been fixed in the 5.0 snapshots, just FYI.
This is fixed in gdb 5.0 snapshots.
GDB 5 is now in Rawhide