It seems that Tcl's Tcl_Alloc, Tcl_Realloc, and Tcl_Free are defined
differently than the ones expected by CRYPTO_set_mem_functions (the
functions are expected to be of void*).  I tried to put a wrapper
around it but I haven't come across much success in that.  I will see
if there are other avenues to this, maybe even using the standard
malloc might do.

On May 6, 6:42 am, Sep Ng <thejackschm...@gmail.com> wrote:
> 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 <je...@activestate.com> 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 
> > > <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.
>
> --
> 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.

Reply via email to