| |
|
Subject: use more caution in testing for pthread_mutex_lock
From a recent bug report on kerberos@mit from Jon DeVree, with some help
in the analysis from Russ Allbery and Sam:
On Linux (GNU libc and friends), if nsswitch.conf enables ldap lookups
for "passwd", and if libnss_ldap pulls in the pthread library (as it
does in Debian "unstable" at the moment), kinit can hang trying to lock
a mutex after the password has been entered, in certain circumstances.
The problem:
Our current thread support tests to see if pthread_mutex_lock is defined
in the C library, and if it is, turns off the run-time weak-reference
test we used to do. I think we used to test just the address of
pthread_mutex_lock, so turning off that test made sense; we do more
thorough tests now.
GNU libc has stub definitions for the pthread_mutex_* functions, so we
can call pthread_mutex_init in the C library. Then when we look up the
name for the current uid via getpwuid (which uses nsswitch, which loads
libnss_ldap) the pthread library gets loaded. Then we call
pthread_mutex_lock from libpthread, which doesn't seem to like the
initialization done by the C library stub. While it can certainly be
argued that this combination of effects is a GNU libc (or ldap library)
bug, we should work around it.
Simple fix: Define USE_PTHREAD_LOCK_ONLY_IF_LOADED on all systems
supporting weak references, even if libc appears to have
pthread_mutex_lock (and even if it's the real thing, and compatible with
the thread library, unless we can identify either the working or failing
systems).
Slightly more complicated fix: USE_PTHREAD_LOCK_ONLY_IF_LOADED and
HAVE_PRAGMA_WEAK_REF are each used in different places to decide whether
to do the run-time test or the unconditional call. We should have only
one macro for this, and probably not make it explicitly dependent on the
#pragma implementation.
|
Download (untitled) 1.7k
|
