This is a discussion on Re: Problem with krb5 1.6 under AIX 5.3 - Kerberos ; > 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 ...
> 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
> 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.
Kerberos mailing list Kerberos@mit.edu