From owner-freebsd-threads@FreeBSD.ORG Thu May 19 13:00:21 2005 Return-Path: Delivered-To: freebsd-threads@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A50DC16A4D0 for ; Thu, 19 May 2005 13:00:21 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7650743DA2 for ; Thu, 19 May 2005 13:00:21 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.13.3/8.13.3) with ESMTP id j4JD0LuM011393 for ; Thu, 19 May 2005 13:00:21 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.13.3/8.13.1/Submit) id j4JD0L8B011392; Thu, 19 May 2005 13:00:21 GMT (envelope-from gnats) Date: Thu, 19 May 2005 13:00:21 GMT Message-Id: <200505191300.j4JD0L8B011392@freefall.freebsd.org> To: freebsd-threads@FreeBSD.org From: Daniel Eischen Subject: Re: threads/81258: Thread specific data is sometimes assigned to multiple keys and/or threads X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Daniel Eischen List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 May 2005 13:00:21 -0000 The following reply was made to PR threads/81258; it has been noted by GNATS. From: Daniel Eischen To: Jens Nilsson Cc: freebsd-gnats-submit@freebsd.org, Subject: Re: threads/81258: Thread specific data is sometimes assigned to multiple keys and/or threads Date: Thu, 19 May 2005 08:52:23 -0400 (EDT) On Thu, 19 May 2005, Jens Nilsson wrote: > Thread specific data is sometimes assinged to multiple keys > and/or threads. In the attached test program two threads getting > the same tsd for the same key seems to be the most usual. > > >How-To-Repeat: > Run the attached test program a couple of times. One of the > threads will wait for input, the bug is most likely to show up if > enter is pressed in about half a second after the thread asked > for data. > > I ran into the bug some time ago while developing a bit more > complex application that involved a couple of threads all of them > with TSD and some doing RPC-calls. In that application I had the > same problem with any of the thread libs libpthread, libthr, and > libc_r. This test program only seems to be able to repeat the > problem with libpthread. Thread-specific data is destroyed when the thread exits. Your TSD is allocated using malloc() and destroyed using free(). Your test program does nothing to ensure that all threads have started running and have all created/initialized their TSD before the first thread exits. malloc() is probably reusing a prior allocation that has been free()'d. Thread exiting != Thread being joined. -- DE