kinit locking up

[Ken Raeburn]

Okay, it looks like Sam and I have tracked it down.  Sam's putting a  
quick fix into Debian package 1.4.3-4, which should be available in  
"unstable" tomorrow afternoon, he tells me.

The problem:

We're calling pthread_mutex_lock unconditionally on systems that have  
weak references (so we can test for the availability of certain  
functions), but which provide a version of the function in the basic  
C library (so, in the older versions of the thread-availability test  
that was less thorough than what we do now, we would always see it).   
It seems that the stub version provided by GNU libc is not compatible  
with the one in the pthread library -- the stub pthread_mutex_init  
sets up a structure that the real pthread_mutex_lock will hang on.

So, I think there's a bug here in one of two places, possibly both:

  - libnss_ldap loads libpthread behind the back of the application

  - libc provides stubs for pthread mutex routines which aren't  
compatible with the libpthread ones, so programs using these routines  
will break if libpthread is loaded while they're running

One could probably argue that programs or libraries calling the  
pthread mutex routines must link against libpthread, but that would  
seem to completely defeat the point of providing stub routines.  If  
the point is to prevent link-time failures in a program that won't  
actually make the calls if it's not multithreaded, well, maybe, but  
then I think weak references are a better way to go.

In any case, we can work around this in the Kerberos code by using  
the same runtime test for calling pthread_mutex_lock and friends as  
we do for other bits of code, where we test for the availability of  
all of the functions we care about, test that pthread_once behaves  
properly (we've seen broken stubs for it!), etc, on systems  
supporting it.  I'll be doing that in the main source tree; Sam's  
quick patch for Debian will cause the run-time weak-reference tests  
to be done always, which should work fine for the GNU libc systems.

Thanks, Jon and Russ, for bringing this to our attention and helping  
us track it down.

Ken