Re: [PATCH] Cygwin 1.2.25+ support via gix in gwlib/conn.c (openssl thread callbacks)

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
-------------------------------------------------------------------