From owner-freebsd-threads@FreeBSD.ORG Mon Oct 13 04:54:38 2003 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 119E816A4B3 for ; Mon, 13 Oct 2003 04:54:38 -0700 (PDT) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mx1.FreeBSD.org (Postfix) with ESMTP id D3C9543FBF for ; Mon, 13 Oct 2003 04:54:36 -0700 (PDT) (envelope-from eischen@vigrid.com) Received: from mail.pcnet.com (mail.pcnet.com [204.213.232.4]) by mail.pcnet.com (8.12.10/8.12.1) with ESMTP id h9DBsZrq004495; Mon, 13 Oct 2003 07:54:36 -0400 (EDT) Date: Mon, 13 Oct 2003 07:54:35 -0400 (EDT) From: Daniel Eischen X-Sender: eischen@pcnet5.pcnet.com To: Doug Rabson In-Reply-To: <1066041497.14360.9.camel@builder02.qubesoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: threads@freebsd.org Subject: Re: GDB and libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: deischen@freebsd.org List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Oct 2003 11:54:38 -0000 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. > > Index: thr_kern.c > =================================================================== > RCS file: /home/ncvs/src/lib/libthr/thread/thr_kern.c,v > retrieving revision 1.13 > diff -u -r1.13 thr_kern.c > --- thr_kern.c 8 Jul 2003 09:58:23 -0000 1.13 > +++ thr_kern.c 12 Oct 2003 12:05:39 -0000 > @@ -80,6 +80,7 @@ > #ifdef _PTHREADS_INVARIANTS > SIGDELSET(set, SIGABRT); > #endif > + SIGDELSET(set, SIGTRAP); > > /* If we have already blocked signals, just up the refcount */ > if (++curthread->signest > 1) > > > -- Dan Eischen