Date: Fri, 26 Mar 2004 18:53:41 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Sean McNeil <sean@mcneil.com> Cc: freebsd-current@freebsd.org Subject: Re: nss_ldap broken Message-ID: <Pine.GSO.4.10.10403261849480.26526-100000@pcnet5.pcnet.com> In-Reply-To: <1080344625.82158.35.camel@server.mcneil.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? -- Dan Eischen
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10403261849480.26526-100000>