Date: 13 Oct 2003 13:22:09 +0100 From: Doug Rabson <dfr@nlsystems.com> To: Daniel Eischen <deischen@FreeBSD.org> Cc: threads@FreeBSD.org Subject: Re: GDB and libthr Message-ID: <1066047729.14360.15.camel@builder02.qubesoft.com> In-Reply-To: <Pine.GSO.4.10.10310130753140.3423-100000@pcnet5.pcnet.com> References: <Pine.GSO.4.10.10310130753140.3423-100000@pcnet5.pcnet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1066047729.14360.15.camel>