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
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:
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:
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