I'll try it. I didn't give it much thought at first but looking at it again, I think it might prevent the long string of ns_free and other calls to free memory after DH_free.
On May 6, 3:43 am, Jeff Hobbs <[email protected]> wrote: > Just starting to look at this, but from the nsopenssl.c I saw another > interesting function not used by TLS: > > if (CRYPTO_set_mem_functions(ns_malloc, ns_realloc, ns_free) == 0) ... > > We could do the same and point to Tcl_Alloc, Tcl_Realloc and Tcl_Free. > I'm not sure they are necessary, and CRYPTO_set_mem_debug_functions > isn't used, but it might help debug. > > On 05/05/2009 12:55 AM, Sep Ng wrote: > > > > > I certainly hope I'm not spamming but this is likely to be the last > > update of the day (at least on my end). > > I wrote a pretty sketchy (and lots of bad programming) but I think I > > *might* have gotten the mutex initialization done. Unfortunately, on > > tests, it falls on a segmentation fault on exactly the same spot > > (DH_free, etc.). > > > Here is the diff right now: > > --- tls.c.back 2009-05-05 10:06:59.000000000 +0800 > > +++ tls.c 2009-05-05 15:41:16.000000000 +0800 > > @@ -130,6 +130,58 @@ > > #define sk_SSL_CIPHER_value( sk, index) (SSL_CIPHER*)sk_value((sk), > > (index)) > > #endif > > > +/* > > + * Thread-Safe TLS Code > > + */ > > + > > +#define OPENSSL_THREAD_DEFINES > > +#include <openssl/opensslconf.h> > > + > > +#if defined(OPENSSL_THREADS) > > + > > +#include <openssl/crypto.h> > > + > > +/* > > + * This is likely to be nasty coding practices > > + * Based from /crypto/cryptlib.c of OpenSSL > > + * Also based on NSOpenSSL > > + * > > + */ > > + > > +Tcl_Mutex locks[CRYPTO_NUM_LOCKS]; > > +size_t num_locks; > > + > > +static void CryptoThreadLockCallback(int mode, int n, const char > > *file, int line); > > +static unsigned long CryptoThreadIdCallback(void); > > + > > +static void > > +CryptoThreadLockCallback(int mode, int n, const char *file, int line) > > +{ > > + if (n >= num_locks) > > + { > > + n = num_locks - 1; > > + } > > + > > + if (mode & CRYPTO_LOCK) > > + { > > + Tcl_MutexLock(&locks[n]); > > + //Tcl_MutexLock(&locks); > > + } > > + else > > + { > > + Tcl_MutexUnlock(&locks[n]); > > + //Tcl_MutexUnlock(&locks); > > + } > > +} > > + > > +static unsigned long > > +CryptoThreadIdCallback(void) > > +{ > > + return (unsigned long) Tcl_GetCurrentThread(); > > +} > > + > > +#endif > > + > > > /* > > *------------------------------------------------------------------- > > @@ -1500,6 +1552,22 @@ > > channelTypeVersion = TLS_CHANNEL_VERSION_1; > > } > > > +#if defined(OPENSSL_THREADS) > > + > > + num_locks = CRYPTO_num_locks(); > > + int lock = 0; > > + for (lock = 0; lock < num_locks; lock++) > > + { > > + TCL_DECLARE_MUTEX(mutex); > > + locks[lock]=mutex; > > + } > > + > > + CRYPTO_set_locking_callback(CryptoThreadLockCallback); > > + CRYPTO_set_id_callback(CryptoThreadIdCallback); > > + > > +#endif > > + > > + > > if (SSL_library_init() != 1) { > > Tcl_AppendResult(interp, "could not initialize SSL library", NULL); > > return TCL_ERROR; > > > We cannot use CRYPTO_lock because CRYPTO_lock calls the function we > > set with CRYPTO_set_locking_callback, so this is completely out of the > > picture. I agree with Jeff that TCL threads and mutex is the right > > way to handle this but I'm wondering if the code I wrote has some > > incorrect implementation, which is leading to still the same crash > > happening. > > > Minor point is that I have yet to find a place to run > > Tcl_Finalize_mutex so we can unload the mutex. Should help prevent > > memory leaks, I think. > > > I will e-mail Jade and Jeff the backtrace as I think it will only muck > > up the discussion. > > > -- > > AOLserver -http://www.aolserver.com/ > > > To Remove yourself from this list, simply send an email to > > <[email protected]> with the > > body of "SIGNOFF AOLSERVER" in the email message. You can leave the > > Subject: field of your email blank. > > -- > AOLserver -http://www.aolserver.com/ > > To Remove yourself from this list, simply send an email to > <[email protected]> with the > body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: > field of your email blank. -- AOLserver - http://www.aolserver.com/ To Remove yourself from this list, simply send an email to <[email protected]> with the body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: field of your email blank.
