Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 23 Mar 2006 22:19:28 +0900
From:      Kazuaki Oda <kaakun@highway.ne.jp>
To:        Kostik Belousov <kostikbel@gmail.com>
Cc:        kan@freebsd.org, hackers@freebsd.org
Subject:   Re: [patch] Re: dlopen() and dlclose() are not MT-safe?
Message-ID:  <4422A060.8090503@highway.ne.jp>
In-Reply-To: <20060323105440.GD27116@deviant.kiev.zoral.com.ua>
References:  <44215FE9.2070602@highway.ne.jp> <20060322174312.GB27116@deviant.kiev.zoral.com.ua> <20060322190725.GC27116@deviant.kiev.zoral.com.ua> <4421BA34.8040908@highway.ne.jp> <20060323105440.GD27116@deviant.kiev.zoral.com.ua>

next in thread | previous in thread | raw e-mail | index | archive | help
Kostik Belousov wrote:
> The reasoning behind releasing the lock is to allow calls to dl*()
> functions from constructors/destructors. This is common practice
> and shall be supported. Yes, leaving the lock taken will lead to
> deadlock.
> 
> Please, try the following patch and report results. I can run (modified *)
> version of your test for some time without crash with both libpthread
> and libthr.
> 
> [* You need to allow for errors in dlopen and just continue the loop.]
> 
> Patch protects access to the list of unloading objects by bind lock,
> and marks the objects that are running finalizers to prevent
> simultaneous loading of them.
> 
> Also, it comments out code that is completely incomprehensible by my sloppy
> brain. Namely, the thread_mask_set stuff seems to allow for the thread
> to run as-is if another thread taken the lock. As result, lock is
> effectively ignored. I cannot understand purpose of this fragments.
> Hope, kan@ describe the reasons.

Thanks.  I tried your patch, and the test program did not crash any 
more.  But I needed to modify it as you say.  IMHO there are probably 
programs in the world that don't retry in case of errors in dlopen(), 
so they still have problems in such case..

--
Kazuaki Oda



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4422A060.8090503>