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
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
