Problem with mutex lock when using credential cache file
huaraz at moeller.plus.com
Sat Jun 10 08:41:58 EDT 2006
I think I tracked it down to a pthread_mutex_lock call in cc_memory.c. When
looking at the man pages it says there are two possibilities why it returns
The pthread_mutex_lock() and pthread_mutex_trylock() functions shall fail
EINVAL The mutex was created with the protocol attribute having the
PTHREAD_PRIO_PROTECT and the calling thread's priority is
higher than the
mutex's current priority ceiling.
The pthread_mutex_lock(), pthread_mutex_trylock(), and
pthread_mutex_unlock() functions may fail if:
EINVAL The value specified by mutex does not refer to an initialized mutex
EAGAIN The mutex could not be acquired because the maximum number of
locks for mutex has been exceeded.
I didn't see anywhere that the mutex was created with PTHREAD_PRIO_PROTECT,
so it refers to an initialized object. Has anybody else experienced this ?
Can anbody point me where to clock for or how to troubleshoot mutex locks ?
"Markus Moeller" <huaraz at moeller.plus.com> wrote in message
news:4483376a$0$30346$ed2619ec at ptn-nntp-reader01.plus.net...
>I have an application that does a krb5_get_init_creds_keytab and stores the
>data in a (memory) credential cache. When the application establishes
>parallel connections with sasl/gssapi authentication or one shortly after
>the other I get a " GSSAPI Error: Miscellaneous failure (Invalid argument)"
>error. I debugged it down to the error code of k5_mutex_lock (error code
>22) somewhere in the cache handling functions. Does anybody know what the
>reason for this error is ? It is pretty impossible to follow the
>k5_mutex_lock inline (re)definitions.
> I am using OpenSolaris 10.1 with krb5-1.4.3.
More information about the Kerberos