From owner-freebsd-threads@FreeBSD.ORG Mon Apr 18 14:00:06 2005 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 77AF916A4CE; Mon, 18 Apr 2005 14:00:06 +0000 (GMT) Received: from mxsf03.cluster1.charter.net (mxsf03.cluster1.charter.net [209.225.28.203]) by mx1.FreeBSD.org (Postfix) with ESMTP id E360243D45; Mon, 18 Apr 2005 14:00:05 +0000 (GMT) (envelope-from archie@dellroad.org) Received: from mxip18.cluster1.charter.net (mxip18a.cluster1.charter.net [209.225.28.148])j3IE042J029623; Mon, 18 Apr 2005 10:00:04 -0400 Received: from cable-68-113-94-164.mtv.al.charter.com (HELO InterJet.dellroad.org) (68.113.94.164) by mxip18.cluster1.charter.net with ESMTP; 18 Apr 2005 10:00:04 -0400 X-Ironport-AV: i="3.92,109,1112587200"; d="scan'208"; a="1030276579:sNHT13626332" Received: from arch20m.dellroad.org (arch20m.dellroad.org [10.2.2.20]) by InterJet.dellroad.org (8.9.1a/8.9.1) with ESMTP id IAA51536; Mon, 18 Apr 2005 08:56:37 -0500 (CDT) Received: from [127.0.0.1] (localhost [127.0.0.1])j3IDuaZK009956; Mon, 18 Apr 2005 08:56:36 -0500 (CDT) (envelope-from archie@dellroad.org) Message-ID: <4263BC94.9040308@dellroad.org> Date: Mon, 18 Apr 2005 08:56:36 -0500 From: Archie Cobbs User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.3) Gecko/20041129 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Eischen References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: David Xu cc: freebsd-threads@freebsd.org Subject: Re: Bug with pthread_getspecific() and signals 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, 18 Apr 2005 14:00:06 -0000 Daniel Eischen wrote: >>Does POSIX say that pthread_getspecific can be used in signal handler ? > > I don't think using it in a signal handler should cause a problem > for our implementation though. Probably the real problem is that > the signal handler is not running in the expected thread. I'd > double check the signal masks and make sure there is only one > thread that could possibly handle the signal. This is a synchronous signal (SIGSEGV) and it's occurring in application code. So it should be delivered to the thread that caused it, right? That's what almost always happens. Also, the this occurs on the second SIGSEGV. When the first one is delivered, pthread_getspecific() and pthread_self() return the correct values. Other random notes: most of the time this bug doesn't happen. However with this particular application, it happens 100% of the time. Still working on a simple test case... if you want a large and complex test case I have that already... :-) -Archie __________________________________________________________________________ Archie Cobbs * CTO, Awarix * http://www.awarix.com