We do see rare reports of assertion failures in the krb5int_key functions, which handle an internal table of thread-specific data keys.<br />
<br />
Ticket 8614 (which you linked to from the stackoverflow answer) happens because krb5int_key_register() is called on a key that is marked as already registered.&nbsp; A candidate explanation there is two different versions of libgssapi_krb5 in the same process, both calling into the same libkrb5support, although I&#39;m not sure that&#39;s right--although it&#39;s easy enough to have multiple versions of libgssapi_krb5 installed on a machine, they should all have the same soname (since we haven&#39;t changed it in a long time), which I think would make it difficult to load more than one version into a process.<br />
<br />
The failure reported here is the inverse:&nbsp;krb5int_key_delete() is called on a key that isn&#39;t marked as registered.&nbsp; krb5int_key_delete() is invoked from the library finalizer of libgssapi_krb5 (also the finalizer of the krb5 version of libcom_err, but typically the e2fsprogs version of com_err is used on Linux).&nbsp; Although it&#39;s possible for the finalizer to run without the initializer having run, there is a check for that.&nbsp; So I don&#39;t have any good theories.