Thanks...
(gdb) print ((krb5_fcc_data *)id->data).lock
$1 = {loc_last = {
filename = 0xb7f26170 "../../../../src/lib/krb5/ccache/cc_file.c",
lineno = 2085},
So, the last action performed on this object by the krb5 mutex macros
was an unlock in the MAYBE_OPEN macro's error handling path...
loc_created = {
filename = 0xb7f26170 "../../../../src/lib/krb5/ccache/cc_file.c",
lineno = 1703},
The mutex was initialized in krb5_fcc_resolve; that's normal.
os = {p = {__m_reserved = 2, __m_count = 1651665711,
__m_owner = 0x6f632e35, __m_kind = 26222, __m_lock = {__status =
2217,
__spinlock = -1209554792}}, owner = 0}, stats = 115 's'}
This is not so normal. The first few fields look like part of an
ASCII string written over a data structure:
0x62726b2f = "brk/"
0x6f632e35 = "oc.5"
Or, reversing for little-endian values, "/krb5.co". That suggests
some memory corruption, or initialization not happening. Could you
try valgrind or electric fence and see if they spot any problems?
I'm trying some builds with the code Sam pointed me to, to see if I
can reproduce the problem with the Debian source tree, though on the
x86_64 system I tried I didn't see any futex calls being made at all...
Ken
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
