kinit locking up

[Ken Raeburn]

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