Problem with mutex lock when using credential cache file

[Markus Moeller]

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" <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.
>
> Thanks
> Markus
>