GDB and libthr

[Doug Rabson]

On Mon, 2003-10-13 at 12:54, Daniel Eischen wrote:
> On 13 Oct 2003, 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.
> > 
> > The simplest change which fixed things for me was to remove SIGTRAP from
> > the list of signals blocked on mutex entry:
> 
> I don't maintain libthr, but this looks OK to me.

Sorry - I saw you comment on a similar message when I did a google
search for gdb+libthr. Who would be a better person to send this to? It
occurred to me that similar severe problems would occur with libthr if
an application took a SIGSEGV, SIGBUS, SIGABORT or any other fatal
unrecoverable signal while holding a mutex.