From owner-freebsd-threads@FreeBSD.ORG Tue Sep 2 01:36:37 2008 Return-Path: Delivered-To: freebsd-threads@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E66211065676; Tue, 2 Sep 2008 01:36:37 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id CC2868FC19; Tue, 2 Sep 2008 01:36:37 +0000 (UTC) (envelope-from davidxu@freebsd.org) Received: from apple.my.domain (root@localhost [127.0.0.1]) by freefall.freebsd.org (8.14.2/8.14.2) with ESMTP id m821aZtZ052213; Tue, 2 Sep 2008 01:36:36 GMT (envelope-from davidxu@freebsd.org) Message-ID: <48BC990C.9020208@freebsd.org> Date: Tue, 02 Sep 2008 09:38:20 +0800 From: David Xu User-Agent: Thunderbird 2.0.0.9 (X11/20080612) MIME-Version: 1.0 To: Kostik Belousov References: <20080830155622.GF2038@deviant.kiev.zoral.com.ua> <20080830184512.GH2038@deviant.kiev.zoral.com.ua> <48BBA369.9010108@freebsd.org> <48BBA925.1000303@icyb.net.ua> <20080901084548.GQ2038@deviant.kiev.zoral.com.ua> <48BBC9A3.1050905@icyb.net.ua> <20080901111215.GS2038@deviant.kiev.zoral.com.ua> <48BBDD6A.60002@icyb.net.ua> <20080901131724.GT2038@deviant.kiev.zoral.com.ua> In-Reply-To: <20080901131724.GT2038@deviant.kiev.zoral.com.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , Andriy Gapon , freebsd-threads@freebsd.org Subject: Re: mysterious hang in pthread_create X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2008 01:36:38 -0000 Kostik Belousov wrote: > On Mon, Sep 01, 2008 at 03:17:46PM +0300, Andriy Gapon wrote: >> on 01/09/2008 14:12 Kostik Belousov said the following: >>> On Mon, Sep 01, 2008 at 01:53:23PM +0300, Andriy Gapon wrote: > ... >>>>>>> The following silly patch fixes the problem Andriy encountered: >>>>>> I can confirm - this fixed the issue for me. >>>>>> David, thanks! >>>>> Does libc_r still work with patch applied ? >>>> In what sense? >>>> The test program that I posted seems to hang in both cases (patched and >>>> unpatched rtld). >>> The David' patch changes the code used to support libc_r operations. >>> Even on CURRENT, if you run 4.x-compiled binary with the support of >>> compat-4x libraries, this code from /libexec/ld-elf.so.1 (installed >>> by CURRENT buildworld) provides locking for rtld. >> I understand, but I am not sure what exactly needs to be tested. >> "Still works" is too broad in this context. > > I am not sure too. As I said, this one of the reason I prefered to not > touch that code. It should not affect other code outside the rtld. In fact, this patch fixes the maintenance of synchronization between locks and thread_flag. In current code, if you acquire a rwlock, and then acquire second rwlock, the first one will work, but acquiring second lock will fail and thread_flag is out of sync, this results bit flag leaking in thread_flag, and later a _rtld_thread_init() call will transfer the unlocked rwlock state to libthr as locked state, also the existing code does not distinguish reader lock and writer lock, it blindly transfer lock state as write-lock, fortunately, in correct case, it should not be called with any lock held, so the transferring does not occur. Another question is why should dl_iterate_phdr() use exclusive lock ? doesn't this cause all C++ exception to be executed in serialization manner ? Regards, David Xu