dlopen/dlclose thread safety

[Carmelo AMOROSO]

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
>