From owner-freebsd-threads@FreeBSD.ORG Fri Dec 26 03:39:09 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 0D54916A4CE for ; Fri, 26 Dec 2003 03:39:09 -0800 (PST) Received: from telecom.net.et (ns2.telecom.net.et [213.55.64.38]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8992343D46 for ; Fri, 26 Dec 2003 03:39:04 -0800 (PST) (envelope-from mtm@identd.net) Received: from [213.55.65.148] (HELO pool-151-200-10-97.res.east.verizon.net) by telecom.net.et (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 32765317; Fri, 26 Dec 2003 14:33:39 +0300 Received: from mobile.acsolutions.com (localhost [127.0.0.1]) ESMTP id hBQBbT2Y000993; Fri, 26 Dec 2003 14:38:00 +0300 (EAT) (envelope-from mtm@mobile.acsolutions.com) Received: (from mtm@localhost) by mobile.acsolutions.com (8.12.10/8.12.10/Submit) id hBQ9i8on008743; Fri, 26 Dec 2003 12:44:08 +0300 (EAT) (envelope-from mtm) Date: Fri, 26 Dec 2003 12:44:08 +0300 From: Mike Makonnen To: Doug Rabson Message-ID: <20031226094408.GA8712@mobile.acsolutions.com> References: <1066052677.14360.29.camel@builder02.qubesoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1066052677.14360.29.camel@builder02.qubesoft.com> User-Agent: Mutt/1.4.1i X-Operating-System: FreeBSD/5.2-CURRENT (i386) cc: threads@freebsd.org Subject: Re: GDB and libthr X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Dec 2003 11:39:09 -0000 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@identd.net | Fingerprint: 00E8 61BC 0D75 7FFB E4D3 6BF1 B239 D010 3215 D418 mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon !