Bug 9373 - gdb can hang loading shared libraries
gdb can hang loading shared libraries
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: gdb (Show other bugs)
6.2
All Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2000-02-11 21:46 EST by Brian Ryner
Modified: 2008-05-01 11:37 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2000-05-30 14:34:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
tom tromey's patch for hashing the symbol table (6.67 KB, patch)
2000-02-18 12:15 EST, Christopher Blizzard
no flags Details | Diff

  None (edit)
Description Brian Ryner 2000-02-11 21:46:01 EST
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.
Comment 1 Christopher Blizzard 2000-02-12 15:30:59 EST
Confirmed.  I see this behavoir as well.
Comment 2 Cristian Gafton 2000-02-17 17:46:59 EST
Jim, any insights into this one?
Comment 3 Christopher Blizzard 2000-02-17 18:01:59 EST
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.
Comment 4 Cristian Gafton 2000-02-17 18:29:59 EST
please submit patches
Comment 5 Jim Kingdon 2000-02-17 18:42:59 EST
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).
Comment 6 Christopher Blizzard 2000-02-18 12:15:59 EST
Created attachment 122 [details]
tom tromey's patch for hashing the symbol table
Comment 7 Christopher Blizzard 2000-02-18 12:18:59 EST
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.
Comment 8 Cristian Gafton 2000-05-22 10:52:59 EDT
assign to jakub
Comment 9 Christopher Blizzard 2000-05-22 15:59:59 EDT
This has been fixed in the 5.0 snapshots, just FYI.
Comment 10 Brian Ryner 2000-05-23 03:15:59 EDT
This is fixed in gdb 5.0 snapshots.
Comment 11 Trond Eivind Glomsrxd 2000-05-30 14:34:59 EDT
GDB 5 is now in Rawhide

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