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
EINVAL.
The pthread_mutex_lock() and pthread_mutex_trylock() functions shall fail
if:
EINVAL The mutex was created with the protocol attribute having the
value
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
object.
EAGAIN The mutex could not be acquired because the maximum number of
recursive
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 ?
Thank you
Markus
"Markus Moeller" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>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.
>
> Thanks
> Markus
>
________________________________________________
Kerberos mailing list [email protected]
https://mailman.mit.edu/mailman/listinfo/kerberos
