dlopen/dlclose thread safety
Carmelo AMOROSO
carmelo.amoroso at st.com
Wed Mar 23 16:29:32 UTC 2011
On 3/23/2011 5:21 PM, Mike Frysinger wrote:
> 2011/3/23 Timo Teräs:
> > Is uclibc dlopen/dlclose thread safe?
>
> last i looked, it was not
>
> > Valgrind says that we always do bad things at:
> > ldso/libdl/libdl.c:453: if (!(runp->tpnt->rtld_flags & RTLD_GLOBAL)) {
> > accessing uninitialized (or unmapped) memory.
>
> i'm sure we do many more bad things ;). look at any place that
> touches static data. like _dl_init in dlopen().
>
> > Could someone with some ld knowledge at least add very basic
> > mutexes to essential parts so that we do not crash?
>
> "very basic" -> "BKL"
>
> > And yes, in libdl.so we should be able to use mutexes at least in NPTL
> > as the main libc.so provides pthread_mutex_* symbols, and forwards them
> > to libpthread if it's loaded. Though depending on how the code is
> > shared, we might need extra care to make sure that the loader .so does
> > not use those (as it can't depend on anything).
>
> glibc seems to get by just fine without mutexes
> -mike
>
Hi,
indeed we have seen also some issue with dlopen, when TLS variables were
involved. One suspect we have is actually thread-safety. glibc use some
locking primitives to access TLS block, while we don't.
Not yet had a free time slot to look at this deeply.
Could you confirm if your issue is related with TLS too ?
Carmelo
_____
__________________________________________
> uClibc mailing list
> uClibc at uclibc.org
> http://lists.busybox.net/mailman/listinfo/uclibc
>
More information about the uClibc
mailing list