[16442] in Kerberos-V5-bugs
[krbdev.mit.edu #8863] krb5int_key_delete: Assertion
daemon@ATHENA.MIT.EDU (Greg Hudson via RT)
Thu Jan 9 19:54:27 2020
From: "Greg Hudson via RT" <rt@KRBDEV-PROD-APP-1.mit.edu>
In-Reply-To: <CAOHeFxfRbS1QzO2y7bVSkOoz-V39wF-ha1376kzHv9z4S7DJfA@mail.gmail.com>
Message-ID: <rt-4.4.4-52662-1578617659-1969.8863-5-0@mit.edu>
To: "AdminCc of krbdev.mit.edu Ticket #8863":;
Date: Thu, 09 Jan 2020 19:54:19 -0500
MIME-Version: 1.0
Reply-To: rt@KRBDEV-PROD-APP-1.mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krb5-bugs-bounces@mit.edu
<URL: https://krbdev.mit.edu/rt/Ticket/Display.html?id=8863 >
We do see rare reports of assertion failures in the krb5int_key functions,
which handle an internal table of thread-specific data keys.
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.
A candidate explanation there is two different versions of libgssapi_krb5 in
the same process, both calling into the same libkrb5support, although I'm not
sure that's right--although it's easy enough to have multiple versions of
libgssapi_krb5 installed on a machine, they should all have the same soname
(since we haven't changed it in a long time), which I think would make it
difficult to load more than one version into a process.
The failure reported here is the inverse: krb5int_key_delete() is called on a
key that isn't marked as registered. 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).
Although it's possible for the finalizer to run without the initializer having
run, there is a check for that. So I don't have any good theories.
_______________________________________________
krb5-bugs mailing list
krb5-bugs@mit.edu
https://mailman.mit.edu/mailman/listinfo/krb5-bugs
