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 > > >>>>>> #22 0xb7e923c3 in TclEvalObjvInternal () from > > >>>>>> /usr/local/tcl/lib/libtcl8.4.so > > >>>>>> #23 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/ > >>>>>> libtcl8.4.so > > >>>>>> #24 0xb7e93635 in Tcl_EvalObjEx () from /usr/local/tcl/lib/ > >>> libtcl8.4.so > > >>>>>> #25 0xb7e9a358 in Tcl_EvalObjCmd () from /usr/local/tcl/lib/ > >>> libtcl8.4.so > > >>>>>> #26 0xb7e923c3 in TclEvalObjvInternal () from > > >>>>>> /usr/local/tcl/lib/libtcl8.4.so > > >>>>>> #27 0xb7ebf0db in TclExecuteByteCode () from > >>>>>> /usr/local/tcl/lib/libtcl8.4.so > > >>>>>> #28 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/ > >>> libtcl8.4.so > > >>>>>> #29 0xb7eefd68 in TclObjInterpProc () from > >>>>>> /usr/local/tcl/lib/libtcl8.4.so > > >>>>>> #30 0xb7e923c3 in TclEvalObjvInternal () from > > ... > > 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.
