nss_ldap broken
Daniel Eischen
eischen at vigrid.com
Thu Apr 1 07:16:56 PST 2004
On Thu, 1 Apr 2004, Jacques A. Vidrine wrote:
> 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.
I don't think that will work; it'll break applications/libraries
not expecting those functions to be NULL.
> (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.
I think the best way is to avoid having shared libraries needlessly linked to
a threads library.
--
Dan Eischen
More information about the freebsd-current
mailing list