Problem with krb5 1.6 under AIX 5.3

[Ken Raeburn]

> OK: test2: Modifications don't corrupt existing open handles
> Assertion failed: destructors_set[keynum] == 0, file  threads.c,  
> line 345

This indicates that there's something wrong with how the library  
initialization or cleanup handlers are being called.  We don't have  
an AIX box to test on, at the moment, but if you could debug it...

This assertion ... hm.  It looks like some library's initialization  
routine is probably being invoked more than once.  On AIX (at least,  
the old version we used to have available for testing), we couldn't  
use weak references to figure out if the thread library was linked  
into a given process, so we should be linking against it  
unconditionally, and I think using pthread_once to invoke the real  
initialization code.  (For startup performance, we use OS library  
termination functions, but not load-time initialization, that's done  
at the entry points to the library.)

Could you check that the pthread library is actually loaded into  
these processes' address spaces?

If that's happening properly, run one of the processes under a  
debugger, and watch the pattern of calls to krb5int_key_register and  
krb5int_key_delete.  Each key number (that gets used in that process  
at all) should be registered once, and then deleted once at process  
exit.  If two registrations of the same number happen without  
deletion, the stack traces of the registrations (ideally with  
debugging info enabled) may be useful for further tracking down the  
problem.


> The same assertion failure we get when we call any of the executables
> (kinit, ...) I've seen this being discussed sometimes in December  
> on the
> list, but I have seen no resolution to it.

Ezra found a race condition in the exiting of a multithreaded process  
where some threads were still doing Kerberos operations while the  
library cleanup handlers were being run.  (We assume a multithreaded  
program unloading the library will first ensure that it's not using  
the code that's being unloaded from other threads, so in the cleanup  
handlers we can free up global storage kept around by the library.   
However, the same cleanup handlers are used at normal process exit,  
where we may not be able to make that assumption.  If we could  
portably distinguish exit() from dlclose(), we'd be okay....)  That  
wouldn't be the case here.

Ken