Date: Thu, 1 Apr 2004 08:36:27 -0600 From: "Jacques A. Vidrine" <nectar@FreeBSD.org> To: Oliver Eikemeier <eikemeier@fillmore-labs.com> Cc: Sean McNeil <sean@mcneil.com> Subject: Re: nss_ldap broken Message-ID: <20040401143627.GA60225@madman.celabo.org> In-Reply-To: <406C217A.8080102@fillmore-labs.com> References: <Pine.GSO.4.10.10404010804250.29968-100000@pcnet5.pcnet.com> <406C217A.8080102@fillmore-labs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 01, 2004 at 04:04:42PM +0200, Oliver Eikemeier wrote:
> Daniel Eischen wrote:
>
> >On Thu, 1 Apr 2004, Oliver Eikemeier wrote:
> [...]
> >>- it should be documented somewhere (bsd.port.mk gives you only
> >>PTHREAD_LIBS)
>
> As far as I understand the problem, every application that doesn't link to
> pthreads, but uses a library that does crashes on -CURRENT. Am I right
> there?
No. Problems only occur if run-time loading/unloading via
dlopen/dlclose is used, and then only if a lock or other thread
library data structure might be held ``across'' the load or unload.
So I think it is a rare, but troublesome, condition.
When you changed the way OpenLDAP was linked, this condition occurred
within libc due to dynamic loading of nss_ldap. So, lots of people's
working systems suddenly starting crashing after upgrading.
I was able to work around the problem in libc, because there, we
have the freedom to putz with internals like __isthreaded. Real
applications don't have that luxury.
[...]
> >I think it is dependent on the library. If the library truly is
> >creating threads behind the scene (suppose there were a libaio)
> >then it needs the threads library.
> >
> >On the other hand, for applications that want to use libaio, you
> >could force them to link to a threads library instead of having
> >it automatically brought in by libaio.
>
> I guess the latter approach will be preferrable, especially since the
> former does seem to trigger the problem we have...
So far no library has been found that does ``the former'' (create
threads behind the scene).
It seems to me we need one of a few things to happen to our threads
implementation*s*:
(a) pthread.h provides all the magic needed to make pthread_*
symbols weak, i.e. transparently providing the functionality of
the `libgcc hack' which Dan says would avoid the problem.
(b) ``somehow'' arrange for the unloading of a thread library to
fixup the pthread stubs `back to normal'. er, that sounds like
a load of work and dangerous to boot.
(c) teach rtld to treat thread libraries specially: ignore them during
dlopen even if they are specified in DT_NEEDED. perhaps we could
add some info to the ELF headers of our thread libraries that rtld
could use to implement this. hacky.
Cheers,
--
Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040401143627.GA60225>