Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 61117 - Race condition between nss/dlopen/thread
Race condition between nss/dlopen/thread
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
Blocks: 61590
  Show dependency treegraph
Reported: 2002-03-13 15:52 EST by hjl
Modified: 2016-11-24 09:56 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-03-26 11:51:47 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
A testcase (1.10 KB, text/plain)
2002-03-13 15:53 EST, hjl
no flags Details

  None (edit)
Description hjl 2002-03-13 15:52:51 EST
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.

Since NSS also does dlopen, I think it should share locks with dlopen.
Comment 1 hjl 2002-03-13 15:53:32 EST
Created attachment 48424 [details]
A testcase
Comment 2 Jakub Jelinek 2002-04-08 09:31:49 EDT
See http://sources.redhat.com/ml/libc-alpha/2002-03/msg00053.html
I agree with Ulrich here, so WONTFIX.

Note You need to log in before you can comment on or make changes to this bug.