X-Mailer: MIME-tools 5.507 (Entity 5.507)
Content-Disposition: inline
In-Reply-To: <CAOHeFxfRbS1QzO2y7bVSkOoz-V39wF-ha1376kzHv9z4S7DJfA@mail.gmail.com>
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: binary
X-RT-Interface: Web
Message-ID: <rt-4.4.4-52662-1578617659-1637.8863-0-0@mit.edu>
MIME-Version: 1.0
References: <CAOHeFxfRbS1QzO2y7bVSkOoz-V39wF-ha1376kzHv9z4S7DJfA@mail.gmail.com>
 <RT-Ticket-8863@mit.edu>
X-RT-Original-Encoding: utf-8
RT-Send-CC:
Content-Length: 1272

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.