From owner-freebsd-threads@FreeBSD.ORG Tue Nov 2 21:11:26 2004 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 8853E16A548 for ; Tue, 2 Nov 2004 21:11:24 +0000 (GMT) Received: from mail3.speakeasy.net (mail3.speakeasy.net [216.254.0.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id 632FA43D1F for ; Tue, 2 Nov 2004 21:11:24 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 2451 invoked from network); 2 Nov 2004 21:11:24 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 2 Nov 2004 21:11:23 -0000 Received: from [10.50.41.235] (gw1.twc.weather.com [216.133.140.1]) (authenticated bits=0) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id iA2LAuYU070948 for ; Tue, 2 Nov 2004 16:11:20 -0500 (EST) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: threads@FreeBSD.org Date: Tue, 2 Nov 2004 17:12:11 -0500 User-Agent: KMail/1.6.2 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200411021712.11115.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx Subject: More mono + libpthread breakage.. 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: Tue, 02 Nov 2004 21:11:26 -0000 It looks like libpthread is not calling _cond_wait_backout() when a thread gets a signal after calling thr_sched_switch() from pthread_cond_wait(). Inside of thr_sched_switch_unlocked(), it leaves a critical section and finds a pending signal, calls thr_sig_defer(). This then calls thr_sig_rundown() with a psf of NULL. thr_sig_rundown() only checks psf's state to see if it needs to call _cond_wait_backout(). In libc_r on 4.x at least the state is always saved into a psf before the equivalent thr_sig_rundown() is called, i.e. it never has a NULL psf. However, deferred signals from kse_critical_leave() are never going to back out a mutex queue or condition variable queue. This kicks in with mono because mono wants to call 'sem_post()' (which is supposed to be signal safe) from a signal handler, but sem_post() calls pthread_mutex_lock() which dies with an assertion error about already being on a syncq since _cond_wait_backout() didn't happen. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org