On 03/23/2011 06:29 PM, Carmelo AMOROSO wrote:
> 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 ?
It is possible. I have NPTL build with errno et al in TLS, and about all
the .so's involved access those. So yes, TLS is certainly involved. But
I cannot for certainty if it's the exact cause here or not.
- Timo
_______________________________________________
uClibc mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/uclibc
