From owner-freebsd-threads@FreeBSD.ORG Mon Oct 13 06:44:43 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 1424516A4B3 for ; Mon, 13 Oct 2003 06:44:43 -0700 (PDT) Received: from mail.qubesoft.com (gate.qubesoft.com [217.169.36.34]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3669843F93 for ; Mon, 13 Oct 2003 06:44:40 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from bluebottle.qubesoft.com (bluebottle.qubesoft.com [192.168.1.2]) by mail.qubesoft.com (8.12.9/8.12.9) with ESMTP id h9DDidFH039906 for ; Mon, 13 Oct 2003 14:44:40 +0100 (BST) (envelope-from dfr@nlsystems.com) Received: from builder02.qubesoft.com (builder02.qubesoft.com [192.168.1.8]) h9DDibbx038207 for ; Mon, 13 Oct 2003 14:44:38 +0100 (BST) (envelope-from dfr@nlsystems.com) From: Doug Rabson To: threads@freebsd.org Content-Type: text/plain Message-Id: <1066052677.14360.29.camel@builder02.qubesoft.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.0 Date: 13 Oct 2003 14:44:37 +0100 Content-Transfer-Encoding: 7bit Subject: 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: Mon, 13 Oct 2003 13:44:43 -0000 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. 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)