dlopen/dlclose thread safety

Timo Teräs timo.teras at iki.fi
Wed Mar 23 08:00:30 UTC 2011


Hi all,

Is uclibc dlopen/dlclose thread safe? It looks like not. I'm currently
trouble shooting issue where I needed to make debug build of uclibc+vlc
and figure the issue out. Turned out that debug build of these very
randomly crashes in dlopen(). gdb says that this happens when two
threads are doing dlopen() and/or dlclose() simultaneously. So I have a
feeling that our implementation is not thread safe.

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.

VLC does lot of loads/unloads to figure out which .so's it wants to use.
So I'd assume this is crashing when one thread is dlopening.

SUPPORT_LD_DEBUG is also garbled because it's printing stuff from two
dlopen() calls from two different threads. What I make of it, we are
completely borked if we try to use dl* multithreadedly. Could someone
with some ld knowledge at least add very basic mutexes to essential
parts so that we do not crash?

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).

Cheers,
 Timo


More information about the uClibc mailing list