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
<lists...@listserv.aol.com> 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
<lists...@listserv.aol.com> with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject:
field of your email blank.
