Re: problems with gdb

[Christopher Blizzard <blizzard at mozilla dot org>]

Tom Tromey wrote:
> 
> >>>>> "Chris" == Chris Blizzard <blizzard@redhat.com> writes:
> 
> Chris>  70.98     19.47    19.47    11954     1.63     2.25  lookup_minimal_symbol
> Chris>  27.12     26.91     7.44 33240213     0.00     0.00  strcmp_iw
> 
> Chris> I'm sorry, is that looking over a linked list?
> Chris> SYMBOL_MATCHES_NAME() is a macro that does some mangling magic
> Chris> so we can't use a standard hash lookup table but there has to
> Chris> be something we can do to speed that up.
> 
> I sent a patch that hugely speeds up lookup_minimal_symbol to
> gdb-patches in November.  Give it a try.  My patch works by keeping
> two hash tables, one of which is used to deal with the mangling
> problem.
> 
> The patch has never been checked into the main line of gdb, but it is
> "known" to be safe -- no test suite regressions from a gdb using it.
> Maybe it will go in someday.

I merged that patch into the most recent version of gdb and all I have
to say is "wow."  It's a lot faster at loading libraries.  I have other,
thread related problems that I'm trying to track down now.  Merging this
patch in seems to have made them worse.

The problem is that something in the pthreads library will rase
SIGTRAP.  I'm rebuilding glibc now to try and track down what exactly is
causing it.  There's also an entry in our debugging faq for mozilla
right now:

http://www.mozilla.org/unix/debugging-faq.html#SIG32

I've got this in my .gdbinit right now:

set auto-solib-add 0
handle SIG32 nostop

When you start up Mozilla you will get these messages from gdb:

nsUnixToolkitService: Using 'gtk' for the Gfx Toolkit.
NS_SetupRegistry() MOZ_TOOLKIT=gtk, WIDGET_DLL=libwidget_gtk.so,
GFX_DLL=libgfx_gtk.so

Program received signal SIG32, Real-time event 32.

Program received signal SIG32, Real-time event 32.

Program received signal SIG32, Real-time event 32.

Program received signal SIG32, Real-time event 32.

Program received signal SIGTRAP, Trace/breakpoint trap.
0x404cbd41 in ?? () from /lib/libc.so.6
(gdb) shar libc.so.6
Reading symbols from /lib/libc.so.6...done.

And here's where it's left:

(gdb) where
#0  0x404cbd41 in __kill () from /lib/libc.so.6
#1  0x40252c73 in __pthread_restart_new (th=0xbf5ffe40) at pthread.c:809
#2  0x4025443c in __pthread_unlock (lock=0x812fd24) at restart.h:21
#3  0x402519bf in __pthread_mutex_unlock (mutex=0x812fd14) at
mutex.c:126
#4  0x4022cc21 in PR_Unlock (lock=0x812fd14) at ptsynch.c:192
#5  0x4022d9bb in PR_ExitMonitor (mon=0x812fd10) at ptsynch.c:520
#6  0x401b7d7c in nsAutoMonitor::~nsAutoMonitor (this=0xbffff188,
__in_chrg=2)
    at ../../dist/include/nsAutoLock.h:188
#7  0x406f4169 in nsFileTransport::OpenInputStream (this=0x812fc00, 
    startPosition=0, readCount=-1, result=0xbffff2c0)
    at nsFileTransport.cpp:602
#8  0x4073bf4c in nsFileChannel::OpenInputStream (this=0x812fad8, 
    startPosition=0, readCount=-1, result=0xbffff2c0) at
nsFileChannel.cpp:189
#9  0x4072d3f0 in nsResChannel::OpenInputStream (this=0x812f200, 
    startPosition=0, readCount=-1, result=0xbffff2c0) at
nsResChannel.cpp:264
#10 0x406baa7e in ?? () at nsResChannel.cpp:353
   from /home/blizzard/src/mozilla/dist/bin/components/libuconv.so
#11 0x406b3d4e in ?? () at nsResChannel.cpp:353
   from /home/blizzard/src/mozilla/dist/bin/components/libuconv.so


-- 
------------
Christopher Blizzard
http://people.redhat.com/blizzard/
------------