On Dec 15, 2005, at 3:04, I wrote:

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.

Okay. I've just managed to reproduce the problem, even if I give a bad password, and it's dependent on whether the "passwd" line in /etc/ nsswitch.conf includes "ldap" or not (before "compat", the other entry there). Unfortunately, in this setup I'm using at the moment, gdb doesn't seem to be working, so I'm going to try a couple other things...

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.

Still haven't figured out why this wouldn't prevent the hang... hence the need for gdb... will keep investigating.

Ken
________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to