Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 26 Mar 2004 15:58:08 -0800
From:      Sean McNeil <sean@mcneil.com>
To:        Daniel Eischen <eischen@vigrid.com>
Cc:        freebsd-current@freebsd.org
Subject:   Re: nss_ldap broken
Message-ID:  <1080345488.10339.3.camel@server.mcneil.com>
In-Reply-To: <Pine.GSO.4.10.10403261849480.26526-100000@pcnet5.pcnet.com>
References:  <Pine.GSO.4.10.10403261849480.26526-100000@pcnet5.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 2004-03-26 at 15:53, Daniel Eischen wrote:
> On Fri, 26 Mar 2004, Sean McNeil wrote:
> 
> > 
> > On Fri, 2004-03-26 at 14:51, Daniel Eischen wrote:
> > > 
> > > I think I made a comment about how you should always
> > > prefix _pthread_foo() calls with 'if (__isthreaded)'.
> > > 
> > > When the thread libraries are initialized, then overrwrite
> > > the function pointers in libc's thread jumptable.  If you
> > > unload the library, libc still retains those pointers.
> > 
> > Yes, checking __isthreaded solves my problem.  nsdispatch.c has several
> > calls to _thread* routines that should be protected by the __isthreaded
> > test.
> > 
> > It would appear that even though RTLD_LOCAL is used on the dlopen, since
> > nss_ldap.so.1 is linked with libc as well it causes those thread
> > jumptable entries to be modified.  When dlclose is called the reference
> > count to the thread library goes to zero, the library is unloaded, and
> > the pointers are now no good.
> > 
> > This poses an interesting problem, though.  Since there is a dlopen in
> > this it is possible for part of a function to have __isthreaded not set
> > and part of it set.  For these routines the value of __isthreaded would
> > need to be stashed.  Yet for the nss_atexit, since it is the opposite
> > direction (dlclose), the variable would have to be tested directly.
> 
> Once something is threaded, I think it always has to be
> threaded.  We don't support going back to unthreaded mode.
> 
> I'm not sure how all this works with nss_ldap (and perhaps
> other modules) and why they are bringing in the threads
> library.  What dependency is bringing in the threads library
> in the first place?

Both nss_ldap.so.1 has some threaded code and one of it's dependencies,
libsasl2.so.2, brings is pthread as well.

Sean




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