On Dec 14, 2005, at 22:39, Russ Allbery wrote:
Below is the interesting bit. valgrind at least thinks that the
mutexes
aren't fully initialized, it looks like, before they're passed into
the
pthread functions. Note that I don't get these same errors when I run
valgrind against the kinit in unstable, so I'm curious about what's
different in your situation.
One thing that I did notice was a bunch of SASL calls earlier on.
I think
the invalid reads there are probably just the standard ld.so noise
that
doesn't appear to mean anything, but their presence indicates that
you're
using some nsswitch module (I'm guessing) that uses SASL. Are you
using
LDAP to do UID lookups, by any chance?
I don't know why that would affect things, but maybe it is.
Aha! I think you may have put your finger on it, Russ.
Part of our approach to dealing with threads has been, when possible,
to give the application writer the option of not linking in the
pthread library, instead using weak references at run time to see if
the library has been loaded. We want programs to be able to
dynamically load and unload the Kerberos and GSSAPI libraries without
ill effects, and the general wisdom seems to be that dynamically
loading a pthread library into a single-threaded program can do Bad
Things, like cause different versions of malloc or other functions to
be seen, when they may not be fully compatible with the versions
already in use by the program.
So now we have another library being loaded somewhere along the way
which causes the pthread library to be loaded (libnss_ldap ->
libldap_r -> libpthread, on my system), and the Kerberos library is
calling pthread_mutex_lock on a structure which it hasn't
initialized, when the LDAP code is loaded.
The strange bit is, in 1.4.3, the Kerberos code should be checking
for the thread support once, and saving away a flag; if it wasn't
loaded at mutex initialization time, we shouldn't be calling
pthread_mutex_lock. If we call pthread_mutex_lock, we should've
decided earlier to call pthread_mutex_init. So I should do some
poking around and see if I can figure out why we still seem to be
behaving differently in the two cases.
In any case, I do think libnss_ldap may have a bug -- I don't think
libpthread should be getting pulled into a single-threaded program
dynamically. Though, if it's guaranteed to be safe with glibc, and
remain safe in future releases, we could consider a Linux- or glibc-
specific change to punt the weak-reference stuff and always pull in
the pthread library ourselves...
Ken
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
