This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
There is a race condition between nss/dlopen/thread. The problem is 1. Thread A has called dlopen, and the global static initialiser inside the shared object that's being dlopened is trying to call getservbyname It's holding the dlopen lock, and trying to acquire the NSS lock. 2. Thread B also calls getservbyname, so we're holding the NSS lock (which thread A is trying to acquire), and NSS is trying to dlopen a shared library. Now. We're deadlocked, because we're trying to acquire the dlopen lock, which is held by thread A. This is obviously quite sensitive to timing. I am enclosing a testcase here. Since NSS also does dlopen, I think it should share locks with dlopen. H.J.
Attachment:
bug.tar.gz
Description: GNU Zip compressed data
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |