[krbdev.mit.edu #8863] krb5int_key_delete: Assertion `destructors_set[keynum] == 1' failed.

Greg Hudson via RT rt at KRBDEV-PROD-APP-1.mit.edu
Fri Jan 10 02:20:22 EST 2020


<URL: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8863 >

There are some theoretically possible execution paths along those lines that
could lead to the assertion failure, but they don't seem likely to be the cause
of the assertion failures you're seeing.

I don't think the interruption scenario is plausible. SIGKILL would abort the
process immediately (no library unloading), as would any unhandled signal. If a
signal arrived, was handled, and the handler returned, the initializer would
continue running and would finish registering all of the keys. Signal handlers
are not allowed to call exit(). Signal handlers are allowed to call _exit(),
but that would bypass library unloading. On top of that, the "graceful reload
or restart" operation would not seem likely to send a signal to processes while
they are in the middle of initializing the GSSAPI library.

The failed initializer scenario actually kind of tracks, because of a bug in
gssint_mechglue_init() (
https://github.com/krb5/krb5/blob/master/src/lib/gssapi/mechglue/g_initialize.c#L106
) where error values can be ignored. (If errors were correctly handled, the
INITIALIZER_RAN() guard in gssint_mechglue_fini() would not consider the
initializer to have run because it returned an error.) But I don't think this
is a likely scenario for two reasons. First, you say you're not using krb5, and
gssint_mechglue_init() doesn't actually run until a GSSAPI function is invoked.
(It's possible that the PHP module invokes a GSSAPI function when it starts up,
I guess.) Second, failures inside gss_krb5int_lib_init() should be vanishingly
uncommon; one doesn't really expect mutex initialization to fail.

I will fix the bug in gssint_mechglue_init(), but to diagnose the actual
problem with any confidence, either I need to be able to reproduce the problem,
or someone who reliably sees the problem needs to debug it in situ, likely by
adding a bunch of instrumentation to the initializer and finalizer code.




More information about the krb5-bugs mailing list