kinit locking up

[Ken Raeburn]

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