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