From owner-freebsd-hackers@FreeBSD.ORG  Wed Mar 22 21:04:18 2006
Return-Path: <owner-freebsd-hackers@FreeBSD.ORG>
X-Original-To: hackers@freebsd.org
Delivered-To: freebsd-hackers@FreeBSD.ORG
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id CF6DC16A424;
	Wed, 22 Mar 2006 21:04:18 +0000 (UTC)
	(envelope-from kaakun@highway.ne.jp)
Received: from mx.highway.ne.jp (pip7.gate01.com [61.122.117.245])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 4D15C43DE9;
	Wed, 22 Mar 2006 21:02:19 +0000 (GMT)
	(envelope-from kaakun@highway.ne.jp)
Received: from [219.0.96.106] (helo=[192.168.11.17])
	by pop12.isp.us-com.jp with esmtp (Mail 4.20)
	id 1FMAT2-0003k1-72; Thu, 23 Mar 2006 06:02:08 +0900
Message-ID: <4421BA34.8040908@highway.ne.jp>
Date: Thu, 23 Mar 2006 05:57:24 +0900
From: Kazuaki Oda <kaakun@highway.ne.jp>
User-Agent: Mozilla Thunderbird 1.0.7 (X11/20051211)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Kostik Belousov <kostikbel@gmail.com>
References: <44215FE9.2070602@highway.ne.jp>
	<20060322174312.GB27116@deviant.kiev.zoral.com.ua>
	<20060322190725.GC27116@deviant.kiev.zoral.com.ua>
In-Reply-To: <20060322190725.GC27116@deviant.kiev.zoral.com.ua>
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: 7bit
Cc: kan@freebsd.org, hackers@freebsd.org
Subject: Re: dlopen() and dlclose() are not MT-safe?
X-BeenThere: freebsd-hackers@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Technical Discussions relating to FreeBSD
	<freebsd-hackers.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>, 
	<mailto:freebsd-hackers-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-hackers>
List-Post: <mailto:freebsd-hackers@freebsd.org>
List-Help: <mailto:freebsd-hackers-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-hackers>,
	<mailto:freebsd-hackers-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 22 Mar 2006 21:04:18 -0000

Kostik Belousov wrote:
> Oops. Completely reversed condition in the if. :(. Also, I don't think it
> shall returns the error in this situation. New take:
> 
> Index: libexec/rtld-elf/rtld.c
> ===================================================================
> RCS file: /usr/local/arch/ncvs/src/libexec/rtld-elf/rtld.c,v
> retrieving revision 1.112
> diff -u -r1.112 rtld.c
> --- libexec/rtld-elf/rtld.c     24 Dec 2005 15:37:30 -0000      1.112
> +++ libexec/rtld-elf/rtld.c     22 Mar 2006 19:03:12 -0000
> @@ -1688,6 +1688,11 @@
>         wlock_release(rtld_bind_lock, lockstate);
>         objlist_call_fini(&list_fini);
>         lockstate = wlock_acquire(rtld_bind_lock);
> +       if (root->refcount != 0) {
> +               wlock_release(rtld_bind_lock, lockstate);
> +               return 0;
> +       }
> +
>         objlist_remove_unref(&list_fini);
> 
>         /* Finish cleaning up the newly-unreferenced objects. */

Thanks.  I applied your patch and ran the test program once more.

When linked with libpthread:
% ./dltest
Segmentation fault (core dumped)

When linked with libthr:
% ./dltest
ld-elf.so.1: assert failed: /usr/src/libexec/rtld-elf/rtld.c:1728

In libpthread case, the result was changed.  I got no "assert failed"
message, and it took longer time to crash than before.  In libthr
case, I could not find any difference.

BTW do you know the reason why lock is released before calling
objlist_call_fini()?  If we don't release the lock, what problem will
occur?  deadlock?

--
Kazuaki Oda