some more debug information for the pthread issues on Cygwin:
as gwlib/conn.c uses our gwthread_self() as callback function for openssl's
CRYPTO_set_id_callback():
/* Return the thread id of this thread. */
long gwthread_self(void)
{
struct threadinfo *threadinfo;
threadinfo = pthread_getspecific(tsd_key);
if (threadinfo)
return threadinfo->number;
else {
printf("XXX gwthread_self with empty threadinfo\n");
return -1;
}
}
we face this output while hitting the mutex panic:
XXX openssl_locking_function 1 u
XXX openssl_locking_function 1 l
XXX openssl_locking_function 1 u
XXX openssl_locking_function 1 l
XXX openssl_locking_function 1 u
XXX openssl_locking_function 1 l
XXX openssl_locking_function 1 2008-07-19 19:37:48.769 [5532] [-1] PANIC:
gwlib/thread.c:142: mutex_lock_real: Managed t
o lock the mutex twice! (Called from
gwlib/conn.c:1251:openssl_locking_function.)
XXX openssl_thread_id 14
XXX openssl_thread_id return 16
XXX openssl_locking_function 1 l
XXX openssl_locking_function 1 u
XXX openssl_locking_function 1 l
XXX openssl_locking_function 1 u
XXX openssl_locking_function 1 l
XXX openssl_locking_function 1 u
XXX gwthread_self with empty threadinfo
XXX openssl_thread_id -1
which means the pthread_getspecific() call fails with return value NULL, meaning
that we don't have an associated thread value for the calling thread.
This shouldn't happen, right?
Stipe
-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------
