As a quick update. I'm using TCL threads to do this. The CRYPTO_* functions are, unsurprisingly used as defaults for openssl. What was happening in my code was that if I set CRYPTO_lock to be the lock callback function, it would end up in an infinite loop.
The problem so far has been that as far as I understand, OpenSSL specifies that the functions must support n mutex locks where n is extracted from CRYPTO_num_locks(). I'll see if it is possible to do this with TCL_DECLARE_MUTEX. I appreciate all the info thus far. :) On May 5, 1:06 pm, Sep Ng <[email protected]> wrote: > Thanks for the link Jeff. I'm still trying to figure out if it's > possible to use CRYPTO_* for the mutex though I agree 100% with you > that if it had been the case, they wouldn't have a need for explicitly > defining the function. > > As of now, using the CRYPTO_lock functions seem to yield some sort of > deadlock where all the threads stop at some point until the SIGSEGV > signal is emitted. The backtrace looks funny so I'll look at TCL > threads after I exhaust this option. > > On May 5, 11:15 am, Jeff Hobbs <[email protected]> wrote: > > > Taking a quick look, that does appear to be perfectly matched to the > > callback that they want. Of course, if that is the case I wonder why > > they say this must be set, rather than making it optional. > > > Otherwise you have Tcl_MutexLock and the related functions mentioned at: > > http://www.tcl.tk/man/tcl8.5/TclLib/Thread.htm > > > For CRYPTO_set_id_callback, it looks like Tcl_GetCurrentThread is the > > right callback. > > > On 4-May-09, at 7:43 PM, Sep Ng wrote: > > > > I'm working on this on behalf of Jade and I'd like to get some info on > > > adding thread safe code on TLS. As noted by Andrew (huge thanks!), > > > TLS does not set the CRYPTO_set_locking_callback and > > > CRYPTO_set_id_callback callback functions which would be required to > > > have TLS thread safe code. I was working on possibly using pthreads > > > for mutex, but came across that OpenSSL does indeed come with Thread > > > support. I would suppose it would be as straight forward as using the > > > mutex designed by OpenSSL (e.g. CRYPTO_lock, etc.). I'd like to know > > > if I'm heading to the right direction with this. I've begun reading > > > up on OpenSSL's threads API but would appreciate any help. > > > > Thank you very much! > > > > On May 5, 6:45 am, Jade Rubick <[email protected]> wrote: > > >> Thank you, Andrew. We'll look into that. > > > >> J > > > >> Jade Rubick > > >> Director of Development > > >> TRUiST > > >> 120 Wall Street, 4th Floor > > >> New York, NY USA > > >> [email protected] > > >> +1 503 285 4963 > > >> +1 707 671 1333 fax > > > >>www.truist.com > > > >> The information contained in this email/document is confidential > > >> and may be > > >> legally privileged. Access to this mail/document by anyone other > > >> than the > > >> intended recipient(s) is unauthorized. If you are not an intended > > >> recipient, > > >> any disclosure, copying, distribution, or any action taken or > > >> omitted to be > > >> taken in reliance to it, is prohibited. > > > >> On Fri, May 1, 2009 at 12:42 PM, Andrew Steets <[email protected]> > > >> wrote: > > >>> It's not a matter of compiling OpenSSL to be thread safe. Someone > > >>> needs to update the TLS C code to call the right OpenSSL API > > >>> functions > > >>> on module initialization. In it's current state I don't see how the > > >>> TLS module can safely call OpenSSL from a threaded context. > > > >>> From the Openssl docs: > > >>>http://openssl.org/docs/crypto/threads.html#DESCRIPTION > > > >>> "OpenSSL can safely be used in multi-threaded applications provided > > >>> that at least two callback functions are set, locking_function and > > >>> threadid_func." > > > >>> The TLS C code doesn't setup either one of those callbacks, so > > >>> that's > > >>> a problem. I'm not sure if that is your problem specifically but it > > >>> would be a good place to start. > > > >>> -Andrew > > > >>> On Fri, May 1, 2009 at 12:59 PM, Jade Rubick <[email protected]> > > >>> wrote: > > > >>>> Jade Rubick > > >>>> Director of Development > > >>>> TRUiST > > >>>> 120 Wall Street, 4th Floor > > >>>> New York, NY USA > > >>>> [email protected] > > >>>> +1 503 285 4963 > > >>>> +1 707 671 1333 fax > > > >>>>www.truist.com > > > >>>> The information contained in this email/document is confidential > > >>>> and may > > >>> be > > >>>> legally privileged. Access to this mail/document by anyone other > > >>>> than > > >>> the > > >>>> intended recipient(s) is unauthorized. If you are not an intended > > >>> recipient, > > >>>> any disclosure, copying, distribution, or any action taken or > > >>>> omitted to > > >>> be > > >>>> taken in reliance to it, is prohibited. > > > >>>> ---------- Forwarded message ---------- > > >>>> From: Jack Schmidt <[email protected]> > > >>>> Date: Thu, Apr 30, 2009 at 4:03 PM > > >>>> Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver > > >>>> To: Jade Rubick <[email protected]> > > >>>> Cc: tech <[email protected]> > > > >>>> I just tried it by recompiling openssl with threads as compiler > > >>>> option > > >>> and > > >>>> it produces the same problem. Maybe there's another way of making > > >>> openssl > > >>>> thread safe. Not sure as of the moment. > > > >>>> 2009/5/1 Jack Schmidt <[email protected]> > > > >>>>> It's certainly a possibility. Since I'm also trying to debianize > > >>> openssl > > >>>>> from Gutsy with debug symbols, we can easily slip in a threaded > > >>>>> build. > > > >>>>> 2009/5/1 Jade Rubick <[email protected]> > > > >>>>>> Maybe we didn't compile openssl to be threadsafe? > > >>>>>> J > > > >>>>>> Jade Rubick > > > >>>>>> Director of Development > > > >>>>>> TRUiST > > > >>>>>> 120 Wall Street, 4th Floor > > > >>>>>> New York, NY 10005 USA > > > >>>>>> [email protected] > > >>>>>> +1 503 285 4963 > > > >>>>>> +1 707 671 1333 fax > > > >>>>>>www.truist.com > > > >>>>>> The information contained in this email/document is > > >>>>>> confidential and > > >>> may > > >>>>>> be legally privileged. Access to this email/document by anyone > > >>>>>> other > > >>> than > > >>>>>> the intended recipient(s) is unauthorized. If you are not an > > >>>>>> intended > > >>>>>> recipient, any disclosure, copying, distribution, or any action > > >>>>>> taken > > >>> or > > >>>>>> omitted to be taken in reliance to it, is prohibited. > > >>>>>> Begin forwarded message: > > > >>>>>> From: Andrew Steets <[email protected]> > > >>>>>> Date: April 29, 2009 6:16:14 PM PDT > > >>>>>> To: [email protected] > > >>>>>> Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver > > >>>>>> Reply-To: AOLserver Discussion <[email protected]> > > >>>>>> Hello, > > > >>>>>> We don't use this TLS package at Wayport, but I have seen similar > > >>>>>> errors with OpenSSL before in other applications. I pulled the > > >>>>>> TLS > > >>>>>> code and glanced through it. It doesn't look like you have > > >>>>>> registered > > >>>>>> the locking callbacks for openssl, which means any openssl > > >>>>>> calls are > > >>>>>> not thread safe. That's going to be a problem inside > > >>>>>> aolserver :-) > > > >>>>>> Check out InitOpenSSL() nsopenssl.c (in the nsopenssl module). > > >>>>>> It > > >>>>>> does all the basic stuff you need to get OpenSSL running in a > > >>>>>> thread-safe manor. > > > >>>>>> Also: http://openssl.org/docs/crypto/threads.html > > > >>>>>> If you 'info threads' and see other threads inside openssl crypto > > >>>>>> functions this is almost certainly your problem. > > > >>>>>> HTH. > > > >>>>>> -Andrew > > > >>>>>> On Wed, Apr 29, 2009 at 5:29 PM, Jade Rubick <[email protected]> > > >>> wrote: > > > >>>>>> Jeff: > > > >>>>>> Here is a backtrace of the crash with 1.6 stable. Did you need > > >>>>>> it from > > >>>>>> head? > > > >>>>>> J > > > >>>>>> Jade Rubick > > > >>>>>> Director of Development > > > >>>>>> TRUiST > > > >>>>>> 120 Wall Street, 4th Floor > > > >>>>>> New York, NY 10005 USA > > > >>>>>> [email protected] > > > >>>>>> +1 503 285 4963 > > > >>>>>> +1 707 671 1333 fax > > > >>>>>>www.truist.com > > > >>>>>> The information contained in this email/document is > > >>>>>> confidential and > > >>> may > > >>>>>> be > > > >>>>>> legally privileged. Access to this email/document by anyone > > >>>>>> other than > > >>>>>> the > > > >>>>>> intended recipient(s) is unauthorized. If you are not an intended > > >>>>>> recipient, > > > >>>>>> any disclosure, copying, distribution, or any action taken or > > >>>>>> omitted > > >>> to > > >>>>>> be > > > >>>>>> taken in reliance to it, is prohibited. > > > >>>>>> Begin forwarded message: > > > >>>>>> TLS BACKTRACE FROM 1.6 stable (without disabling DH) > > > >>>>>> Complete backtrace: > > > >>>>>> (gdb) bt > > > >>>>>> #0 0xffffe410 in __kernel_vsyscall () > > > >>>>>> #1 0xb7cd4875 in raise () from /lib/tls/i686/cmov/libc.so.6 > > > >>>>>> #2 0xb7cd6201 in abort () from /lib/tls/i686/cmov/libc.so.6 > > > >>>>>> #3 0xb7ee7a4f in Tcl_PanicVA () from /usr/local/tcl/lib/ > > >>>>>> libtcl8.4.so > > > >>>>>> #4 0xb7ee7a77 in Tcl_Panic () from /usr/local/tcl/lib/ > > >>>>>> libtcl8.4.so > > > >>>>>> #5 0xb7ef6b4f in Ptr2Block () from /usr/local/tcl/lib/ > > >>>>>> libtcl8.4.so > > > >>>>>> #6 0xb7ef7117 in TclpFree () from /usr/local/tcl/lib/ > > >>>>>> libtcl8.4.so > > > >>>>>> #7 0xb7e9751d in Tcl_Free () from /usr/local/tcl/lib/ > > >>>>>> libtcl8.4.so > > > >>>>>> #8 0xb7f27251 in ns_free () from > > > >>>>>> /usr/local/aolserver40r10/lib/libnsthread.so > > > >>>>>> #9 0xb605c4aa in CRYPTO_free () from > > >>>>>> /usr/lib/i686/cmov/libcrypto.so.0.9.8 > > > >>>>>> #10 0xb60890aa in BN_clear_free () from > > > >>>>>> /usr/lib/i686/cmov/libcrypto.so.0.9.8 > > > >>>>>> #11 0xb60b0836 in DH_free () from /usr/lib/i686/cmov/ > > >>>>>> libcrypto.so.0.9.8 > > > >>>>>> #12 0xa1ffa1e5 in CTX_Init (statePtr=0x139ce5c0, proto=3, > > >>>>>> key=0x0, > > >>>>>> cert=0x0, > > > >>>>>> CAdir=0x0, CAfile=0x0, ciphers=0x0) at tls.c:1015 > > > >>>>>> #13 0xa1ff9a72 in ImportObjCmd (clientData=0x0, > > >>>>>> interp=0x16403240, > > >>>>>> objc=4, > > > >>>>>> objv=0xa97f96bc) at tls.c:800 > > > >>>>>> #14 0xb7e923c3 in TclEvalObjvInternal () from > > > >>>>>> /usr/local/tcl/lib/libtcl8.4.so > > > >>>>>> #15 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/ > > >>>>>> libtcl8.4.so > > > >>>>>> #16 0xb7e93635 in Tcl_EvalObjEx () from /usr/local/tcl/lib/ > > >>> libtcl8.4.so > > > >>>>>> #17 0xb7e9a358 in Tcl_EvalObjCmd () from /usr/local/tcl/lib/ > > >>> libtcl8.4.so > > > >>>>>> #18 0xb7e923c3 in TclEvalObjvInternal () from > > > >>>>>> /usr/local/tcl/lib/libtcl8.4.so > > > >>>>>> #19 0xb7ebf0db in TclExecuteByteCode () from > > >>>>>> /usr/local/tcl/lib/libtcl8.4.so > > > >>>>>> #20 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/ > > >>> libtcl8.4.so > > > >>>>>> #21 0xb7eefd68 in TclObjInterpProc () from > > >>>>>> /usr/local/tcl/lib/libtcl8.4.so > > ... > > read more ยป -- 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.
