GDB and libthr

[Mike Makonnen]

On Mon, Oct 13, 2003 at 02:44:37PM +0100, Doug Rabson wrote:
> I just upgraded one of my systems to the latest current and I came
> across some problems with libthr. A program which I was working on
> suddenly found itself linked against libthr (presumably because of a new
> version of libmap.conf or similar) and I found myself completely unable
> to debug it. This was not a threaded application, merely one which had
> linked against libthr.
> 
> The symtoms are that when running the application under gdb, it quickly
> hangs and starts consuming as much CPU time as it can. I looked into
> things carefully and at the bottom of things, I discovered that when a
> libthr mutex is held, the process blocks out SIGTRAP (among other
> things). If the application hits a breakpoint while the mutex is held,
> everything quickly goes pear shaped since the application doesn't get
> the SIGTRAP. Basically it gets into a tight loop of hitting the
> breakpoint, getting a signal, ignoring it and then trying to execute the
> breakpoint instruction again.
> 
> Since this also happens when dlopen is called (there is always a
> breakpoint inside the dynamic linker to keep GDB's list of shared
> libraries up to date) and since comon apis such as getpwuid end up in
> dlopen via nsdispatch, it becomes impossible to run many applications
> even without setting breakpoints. Also, if an application happens to
> take a non-recoverable fatal signal such as SIGSEGV, SIGBUS, SIGSYS or
> similar while holding a mutex, it will wedge itself in a tight loop in a
> similar way, whether or not it is running under GDB.
> 
> The simplest change which fixed things for me was to remove SIGTRAP from
> the list of signals blocked on mutex entry. This does not fix the
> similar problems with SIGSEGV etc.
> 

Sorry for getting back to you so late, but I was away for a while, and it's
taking some time to catch up with mail :(.

Yes, you're right: the list of caught and blocked signals in libthr needs to be
revised and fixed. It's on the *big* list of TODOs for libthr :-)

Feel free to commit the patch, and I'll take a look at revising the status
of the rest of the signals.

Cheers.
-- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
mtm at identd.net | Fingerprint: 00E8 61BC 0D75 7FFB E4D3  6BF1 B239 D010 3215 D418
mtm at FreeBSD.Org| FreeBSD - Unleash the Daemon !