[AOLSERVER] TLS 1.6 and Aolserver

[Jade Rubick]

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
jrub...@truist.com
+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  0xe410 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 /usr/local/tcl/lib/ 
libtcl8.4.so
#31 0xb7ebf0db in TclExecuteByteCode () from /usr/local/tcl/lib/ 
libtcl8.4.so
#32 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/ 
libtcl8.4.so
#33 0xb7e93539 in Tcl_EvalObjEx () from /usr/local/tcl/lib/ 
libtcl8.4.so

#34 0xb7e9fe07 in Tcl_IfObjCmd () from /usr/local/tcl/lib/libtcl8.4.so
#35 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ 
libtcl8.4.so

#36 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so
#37 0xb7edcccb in Tcl_FSEvalFile () from /usr/local/tcl/lib/ 
libtcl8.4.so
#38 0xb7ea5f16 in Tcl_SourceObjCmd () from /usr/local/tcl/lib/ 
libtcl8.4.so
#39 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ 
libtcl8.4.so

#40 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so
#41 0xb7e93635 in Tcl_EvalObjEx () from /usr/local/tcl/lib/ 
libtcl8.4.so
#42 0xb7ee3cf1 in Tcl_NamespaceObjCmd () from /usr/local/tcl/lib/ 
libtcl8.4.so
#43 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ 
libtcl8.4.so
#44 0xb7ebf0db in TclExecuteByteCode () from /usr/local/tcl/lib/ 
libtcl8.4.so
#45 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/ 
libtcl8.4.so
#46 0xb7eefd68 in TclObjInterpProc () from /usr/local/tcl/lib/ 
libtcl8.4.so
#47 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ 
libtcl8.4.so

#48 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so
#49 0xb7e93635 in Tcl_EvalObjEx () from /usr/local/tcl/lib/ 
libtcl8.4.so
#50 0xb7ef05bd in Tcl_UplevelObjCmd () from /usr/local/tcl/lib/ 
libtcl8.4.so
#51 0xb7e923c3 in TclEvalObjvInternal () from /usr/local/tcl/lib/ 
libtcl8.4.so
#52 0xb7ebf0db in TclExecuteByteCode () from /usr/local/tcl/lib/ 
libtcl8.4.so
#53 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/ 
libtcl8.4.so
#54 0xb7eefd68 in TclObjInterpProc () from /usr/local/tcl/lib/ 
libtcl8.4.so
#55 0xb7ee13c9 in InvokeImportedCmd () from /usr/local/tcl/lib/ 
libtcl8.4.so
#56 0xb7e9

Re: [AOLSERVER] TLS 1.6 and Aolserver

[Jeff Hobbs]

On 29/04/2009 3:29 PM, Jade Rubick wrote:

Here is a backtrace of the crash with 1.6 stable. Did you need it from head?


No, that is the correct tls.c.  I'm curious what the value of ctx and dh 
are in stack frame #11 (at DH_free).  Tcl_Panic should be passing a 
clear message to - what is that?  It may be trying to free memory from a 
different thread.  I am also suspicious about the several different 
*_free functions that are taking place here.  DH_free shouldn't trigger 
such a chain from what I can see.


This may be some interaction case specific to AOLServer use as well, 
with the ns_free layering over the threaded Tcl allocator.


Can't really say much else, except that it does work without the other 
components involved.


Jeff


TLS BACKTRACE FROM 1.6 stable (without disabling DH)

*Complete backtrace:*
(gdb) bt
#0  0xe410 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 

...

*Offending frame in stack:*
*#12 0xa1ffa1e5 in CTX_Init (statePtr=0x139ce5c0, proto=3, key=0x0, 
cert=0x0,

CAdir=0x0, CAfile=0x0, ciphers=0x0) at tls.c:1015
1015DH_free(dh);



--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to 
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Re: [AOLSERVER] TLS 1.6 and Aolserver

[Andrew Steets]

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  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
>
> jrub...@truist.com
> +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  0xe410 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
> /usr/local/tcl/lib/libtcl8.4.so
> #31 0xb7ebf0db in TclExecuteByteCode () from /usr/local/tcl/lib/libtcl8.4.so
> #32 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/libtcl8.4.so
> #33 0xb7e93539 in Tcl_EvalObjEx () from /usr/local/tcl/lib/libtcl8.4.so
> #34 0xb7e9fe07 in Tcl_IfObjCmd () from /usr/local/tcl/lib/libtcl8.4.so
> #35 0xb7e923c3 in TclEvalObjvInternal () from
> /usr/local/tcl/lib/libtcl8.4.so
> #36 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so
> #37 0xb7edcccb in Tcl_FSEvalFile () from /usr/local/tcl/lib/libtcl8.4.so
> #38 0xb7ea5f16 in Tcl_SourceObjCmd () from /usr/local/tcl/lib/libtcl8.4.so
> #39 0xb7e923c3 in TclEvalObjvInternal () from
> /usr/local/tcl/lib/libtcl8.4.so
> #40 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so
> #41 0xb7e93635 in Tcl_EvalObjEx () from /usr/local/tcl/lib/libtcl8.4.so
> #42 0xb7ee3cf1 in Tcl_NamespaceObjCmd () from
> /usr/local/tcl/lib/libtcl8.4.so
> #43 0xb7e923c3 in TclEvalObjvInternal () from
> /usr/local/tcl/lib/libtcl8.4.so
> #44 0xb7ebf0db in TclExecuteByteCode () from /usr/local/tcl/lib/libtcl8.4.so
> #45 0xb7ec2dbc in TclCompEvalO

Re: [AOLSERVER] TLS 1.6 and Aolserver

[Jade Rubick]

Thank you, Andrew. We'll check into that.

J

Jade Rubick
Director of Development
TRUiST
120 Wall Street, 4th Floor
New York, NY 10005 USA
jrub...@truist.com
+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.


On Apr 29, 2009, at 6:16 PM, Andrew Steets wrote:


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   
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

jrub...@truist.com
+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  0xe410 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
/usr/local/tcl/lib/libtcl8.4.so
#31 0xb7ebf0db in TclExecuteByteCode () from /usr/local/tcl/lib/ 
libtcl8.4.so
#32 0xb7ec2dbc in TclCompEvalObj () from /usr/local/tcl/lib/ 
libtcl8.4.so
#33 0xb7e93539 in Tcl_EvalObjEx () from /usr/local/tcl/lib/ 
libtcl8.4.so
#34 0xb7e9fe07 in Tcl_IfObjCmd () from /usr/local/tcl/lib/ 
libtcl8.4.so

#35 0xb7e923c3 in TclEvalObjvInternal () from
/usr/local/tcl/lib/libtcl8.4.so
#36 0xb7e92987 in Tcl_EvalEx () from /usr/local/tcl/lib/libtcl8.4.so
#37 0xb7edcccb in Tcl_FSEvalFile () from /usr/local/tcl/lib/ 
libtcl8.4.so
#38 0xb7ea5f16 in Tcl_SourceObjCmd () from /usr/

Re: [AOLSERVER] TLS 1.6 and Aolserver

[Jeff Hobbs]

If Diffie Helmann is the only real issue here, maybe this should also be 
considered and DH removed by default configure.


https://sourceforge.net/tracker/?func=detail&aid=1811445&group_id=13248&atid=313248

Jeff

On 06/05/2009 6:45 PM, Sep Ng wrote:

Hi Jeff,

I'm going to review options on how to progress with this problem with
Jade.  I've traced and stepped into TlsInit, and CtxInit functions and
as far as I can see, the mutex functions we wrote seems to be
working.  I wonder if there is some influence by aolserver or what
not.  I don't know.  It also seems that allow_customize in
CRYPTO_set_mem_functions is getting set to zero for some reason.  I'm
not totally sure why that is happening.

At this moment, I don't know what to do.

On May 7, 7:14 am, Jack Schmidt  wrote:

Hi, Sep here.

I just tried by disabling nsopenssl and it crashes at the same point.  I
suppose this is definitely more related to using aolserver with tls.  I've
included a backtrace and it shows the same point of failure.

We use aolserver 4.0.10, though I'm not sure how relevant it is to the
discussion.  I'll try to check the startup routine of aolserver and see if I
can find anything.

2009/5/7 Jeff Hobbs 




Is it possible that both nsopenssl and tls are in use, and that they both
might be initializing openssl in the same process?  I'm not sure if this
would be a support case if so.
On 05/05/2009 6:16 PM, Sep Ng wrote:

Hi Jeff,
I took a closer look at the patch you posted.  It seems that the
CRYPTO_set_mem_functions is not succeeding.  The default memory
functions that CRYPTO uses are malloc, realloc, and free but from the
back trace, it looks like ns_malloc, ns_realloc and ns_free are the
ones being used for some reason.  I think I'm running out of ideas
here.  It's unclear why CRYPTO_set_mem_function would return 0 instead
of 1, unless it's some bug in my OpenSSL package in Ubuntu.
On May 6, 8:42 am, Jack Schmidt  wrote:

I've just yanked the debug.  This includes the backtrace and memory frame
info and the local info for most of the frames up until #11 CTX_Init.  As
before, the crash happens when DH_free is called.
2009/5/6 Jeff Hobbs 
 Of the presented patches, I didn't find one that seemed to actually

work,
so I wrote one based on those presented.  It is attached.  Please test
it in
your environments.  I have tested that it passes the basic tls test
suite
against a threaded Tcl 8.5.7 core build on Linux-x64 (and verified that
OPENSSL_THREADS was true for this install).
This patch is against tls 1.6 head.
Jeff
On 05/05/2009 3:42 PM, Sep Ng 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  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.

   

--
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.

--
"A scrum a day keeps the pigs at bay"

--
AOLserver -http://www.aolserver.com/

To Remove yourself from this list, simply send an email to 
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

 bt-without-nsopenssl
17KViewDownload



--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to 
 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 
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Re: [AOLSERVER] TLS 1.6 and Aolserver

[Sep Ng]

Hi Jeff,

Thank you for the link to the bug tracker ticket.  Perhaps I can
suggest to Jade to go with disabling DH.  Thank you so much for your
time.

On May 8, 6:25 am, Jeff Hobbs  wrote:
> If Diffie Helmann is the only real issue here, maybe this should also be
> considered and DH removed by default configure.
>
> https://sourceforge.net/tracker/?func=detail&aid=1811445&group_id=132...
>
> Jeff
>
> On 06/05/2009 6:45 PM, Sep Ng wrote:
>
>
>
> > Hi Jeff,
>
> > I'm going to review options on how to progress with this problem with
> > Jade.  I've traced and stepped into TlsInit, and CtxInit functions and
> > as far as I can see, the mutex functions we wrote seems to be
> > working.  I wonder if there is some influence by aolserver or what
> > not.  I don't know.  It also seems that allow_customize in
> > CRYPTO_set_mem_functions is getting set to zero for some reason.  I'm
> > not totally sure why that is happening.
>
> > At this moment, I don't know what to do.
>
> > On May 7, 7:14 am, Jack Schmidt  wrote:
> >> Hi, Sep here.
>
> >> I just tried by disabling nsopenssl and it crashes at the same point.  I
> >> suppose this is definitely more related to using aolserver with tls.  I've
> >> included a backtrace and it shows the same point of failure.
>
> >> We use aolserver 4.0.10, though I'm not sure how relevant it is to the
> >> discussion.  I'll try to check the startup routine of aolserver and see if 
> >> I
> >> can find anything.
>
> >> 2009/5/7 Jeff Hobbs 
>
> >>> Is it possible that both nsopenssl and tls are in use, and that they both
> >>> might be initializing openssl in the same process?  I'm not sure if this
> >>> would be a support case if so.
> >>> On 05/05/2009 6:16 PM, Sep Ng wrote:
>  Hi Jeff,
>  I took a closer look at the patch you posted.  It seems that the
>  CRYPTO_set_mem_functions is not succeeding.  The default memory
>  functions that CRYPTO uses are malloc, realloc, and free but from the
>  back trace, it looks like ns_malloc, ns_realloc and ns_free are the
>  ones being used for some reason.  I think I'm running out of ideas
>  here.  It's unclear why CRYPTO_set_mem_function would return 0 instead
>  of 1, unless it's some bug in my OpenSSL package in Ubuntu.
>  On May 6, 8:42 am, Jack Schmidt  wrote:
> > I've just yanked the debug.  This includes the backtrace and memory 
> > frame
> > info and the local info for most of the frames up until #11 CTX_Init.  
> > As
> > before, the crash happens when DH_free is called.
> > 2009/5/6 Jeff Hobbs 
> >  Of the presented patches, I didn't find one that seemed to actually
> >> work,
> >> so I wrote one based on those presented.  It is attached.  Please test
> >> it in
> >> your environments.  I have tested that it passes the basic tls test
> >> suite
> >> against a threaded Tcl 8.5.7 core build on Linux-x64 (and verified that
> >> OPENSSL_THREADS was true for this install).
> >> This patch is against tls 1.6 head.
> >> Jeff
> >> On 05/05/2009 3:42 PM, Sep Ng 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  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.
> >>>
> >>> --
> >>> 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.
> >> --
> >> "A scrum a day keeps the pigs at bay"
>
> >> --
> >> AOLserver -http://www.aolserver.com/
>
> >> To Remove yourself from this list, simply send an email to 
> >>  with the
> >> body of "SIGNOFF AOLSERVER" in the email message. You can leave the 
> >> Subject: field of your email blank.
>
> >>  bt-without-nsopenssl
> >> 17KViewDownload
>
> > --
> > AOLserver -http://www.aolserver.com/
>
> > To Remove yourself from this list, simply send an email to 
> >  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 
>  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 s

Re: [AOLSERVER] TLS 1.6 and Aolserver

[Jade Rubick]

That makes sense to me. It does basically the same thing as what Sep  
suggested earlier to disable DH. I'm not sure if there are any  
problems with doing so, but looking at that bug report, it looks like  
it might be a good idea.


J


Jade Rubick
Director of Development
TRUiST
120 Wall Street, 4th Floor
New York, NY 10005 USA
jrub...@truist.com
+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.


On May 7, 2009, at 3:25 PM, Jeff Hobbs wrote:

If Diffie Helmann is the only real issue here, maybe this should  
also be considered and DH removed by default configure.


https://sourceforge.net/tracker/?func=detail&aid=1811445&group_id=13248&atid=313248

Jeff

On 06/05/2009 6:45 PM, Sep Ng wrote:

Hi Jeff,
I'm going to review options on how to progress with this problem with
Jade.  I've traced and stepped into TlsInit, and CtxInit functions  
and

as far as I can see, the mutex functions we wrote seems to be
working.  I wonder if there is some influence by aolserver or what
not.  I don't know.  It also seems that allow_customize in
CRYPTO_set_mem_functions is getting set to zero for some reason.  I'm
not totally sure why that is happening.
At this moment, I don't know what to do.
On May 7, 7:14 am, Jack Schmidt  wrote:

Hi, Sep here.

I just tried by disabling nsopenssl and it crashes at the same  
point.  I
suppose this is definitely more related to using aolserver with  
tls.  I've

included a backtrace and it shows the same point of failure.

We use aolserver 4.0.10, though I'm not sure how relevant it is to  
the
discussion.  I'll try to check the startup routine of aolserver  
and see if I

can find anything.

2009/5/7 Jeff Hobbs 



Is it possible that both nsopenssl and tls are in use, and that  
they both
might be initializing openssl in the same process?  I'm not sure  
if this

would be a support case if so.
On 05/05/2009 6:16 PM, Sep Ng wrote:

Hi Jeff,
I took a closer look at the patch you posted.  It seems that the
CRYPTO_set_mem_functions is not succeeding.  The default memory
functions that CRYPTO uses are malloc, realloc, and free but  
from the
back trace, it looks like ns_malloc, ns_realloc and ns_free are  
the

ones being used for some reason.  I think I'm running out of ideas
here.  It's unclear why CRYPTO_set_mem_function would return 0  
instead

of 1, unless it's some bug in my OpenSSL package in Ubuntu.
On May 6, 8:42 am, Jack Schmidt  wrote:
I've just yanked the debug.  This includes the backtrace and  
memory frame
info and the local info for most of the frames up until #11  
CTX_Init.  As

before, the crash happens when DH_free is called.
2009/5/6 Jeff Hobbs 
Of the presented patches, I didn't find one that seemed to  
actually

work,
so I wrote one based on those presented.  It is attached.   
Please test

it in
your environments.  I have tested that it passes the basic tls  
test

suite
against a threaded Tcl 8.5.7 core build on Linux-x64 (and  
verified that

OPENSSL_THREADS was true for this install).
This patch is against tls 1.6 head.
Jeff
On 05/05/2009 3:42 PM, Sep Ng 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  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.

  

--
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.

--
"A scrum a day keeps the pigs at bay"

--
AOLserver -http://www.aolserver.com/

To Remove yourself from this list, simply send an email to  
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave  
the Subject: field of your email blank.


bt-without-nsopenssl
17KViewDownload

--
AOLserver - http://www.aolserver.com/
To Remove yourself from this list, simply send an email to > 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 > with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the  
Subject: field of your email blank.




-

[AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Jade Rubick]

Jade Rubick
Director of Development
TRUiST
120 Wall Street, 4th Floor
New York, NY USA
jrub...@truist.com
+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 
Date: Thu, Apr 30, 2009 at 4:03 PM
Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver
To: Jade Rubick 
Cc: tech 


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 

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 
>
> 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
>>
>> jrub...@truist.com
>> +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 
>> *Date: *April 29, 2009 6:16:14 PM PDT
>> *To: *aolser...@listserv.aol.com
>> *Subject: **Re: [AOLSERVER] TLS 1.6 and Aolserver*
>> *Reply-To: *AOLserver Discussion 
>>
>> 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  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
>>
>>
>> jrub...@truist.com
>>
>> +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  0xe410 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/lib

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Andrew Steets]

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  wrote:
>
> Jade Rubick
> Director of Development
> TRUiST
> 120 Wall Street, 4th Floor
> New York, NY USA
> jrub...@truist.com
> +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 
> Date: Thu, Apr 30, 2009 at 4:03 PM
> Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver
> To: Jade Rubick 
> Cc: tech 
>
>
> 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 
>>
>> 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 
>>>
>>> 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
>>>
>>> jrub...@truist.com
>>> +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 
>>> Date: April 29, 2009 6:16:14 PM PDT
>>> To: AOLSERVER@LISTSERV.AOL.COM
>>> Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver
>>> Reply-To: AOLserver Discussion 
>>> 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  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
>>>
>>> jrub...@truist.com
>>>
>>> +1 503 285 4963
>>>
>>> +1 707 671 1333 fax
>>>
>>> www.truist.com
>>>
>>> The information contained in this email/document is confidential and may
>>> be
>>>
>>> lega

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Jade Rubick]

Thank you, Andrew. We'll look into that.

J

Jade Rubick
Director of Development
TRUiST
120 Wall Street, 4th Floor
New York, NY USA
jrub...@truist.com
+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  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  wrote:
> >
> > Jade Rubick
> > Director of Development
> > TRUiST
> > 120 Wall Street, 4th Floor
> > New York, NY USA
> > jrub...@truist.com
> > +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 
> > Date: Thu, Apr 30, 2009 at 4:03 PM
> > Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver
> > To: Jade Rubick 
> > Cc: tech 
> >
> >
> > 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 
> >>
> >> 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 
> >>>
> >>> 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
> >>>
> >>> jrub...@truist.com
> >>> +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 
> >>> Date: April 29, 2009 6:16:14 PM PDT
> >>> To: AOLSERVER@LISTSERV.AOL.COM
> >>> Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver
> >>> Reply-To: AOLserver Discussion 
> >>> 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 

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Sep Ng]

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  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
> jrub...@truist.com
> +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  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  wrote:
>
> > > Jade Rubick
> > > Director of Development
> > > TRUiST
> > > 120 Wall Street, 4th Floor
> > > New York, NY USA
> > > jrub...@truist.com
> > > +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 
> > > Date: Thu, Apr 30, 2009 at 4:03 PM
> > > Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver
> > > To: Jade Rubick 
> > > Cc: tech 
>
> > > 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 
>
> > >> 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 
>
> > >>> 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
>
> > >>> jrub...@truist.com
> > >>> +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,

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Jeff Hobbs]

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  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
jrub...@truist.com
+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   
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   
wrote:



Jade Rubick
Director of Development
TRUiST
120 Wall Street, 4th Floor
New York, NY USA
jrub...@truist.com
+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 
Date: Thu, Apr 30, 2009 at 4:03 PM
Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver
To: Jade Rubick 
Cc: tech 


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 



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 



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



jrub...@truist.com
+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 
Date: April 29, 2009 6:16:14 PM PDT
To: aolser...@listserv.aol.com
Subject: Re: [AOLSERVER] TLS 1.6 and Aolserver
Reply-To: AOLserver Discussion 
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

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Sep Ng]

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  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  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
> >> jrub...@truist.com
> >> +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 
> >> 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 
> >>> wrote:
>
> >>>> Jade Rubick
> >>>> Director of Development
> >>>> TRUiST
> >>>> 120 Wall Street, 4th Floor
> >>>> New York, NY USA
> >>>> jrub...@truist.com
> >>>> +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 

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Sep Ng]

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  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  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  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
> > >> jrub...@truist.com
> > >> +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 
> > >> 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 
> > >>> wrote:
>
> > >>>> Jade Rubick
> > >>>> Director of Development
> > &

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Sep Ng]

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.0 +0800
+++ tls.c   2009-05-05 15:41:16.0 +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 
+
+#if defined(OPENSSL_THREADS)
+
+#include 
+
+/*
+ * 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 
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Jeff Hobbs]

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.0 +0800
+++ tls.c   2009-05-05 15:41:16.0 +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 
+
+#if defined(OPENSSL_THREADS)
+
+#include 
+
+/*
+ * 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 
 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 
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Sep Ng]

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  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.0 +0800
> > +++ tls.c  2009-05-05 15:41:16.0 +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 
> > +
> > +#if defined(OPENSSL_THREADS)
> > +
> > +#include 
> > +
> > +/*
> > + * 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 
> >  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 
>  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 
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Jeff Hobbs]

Of the presented patches, I didn't find one that seemed to actually 
work, so I wrote one based on those presented.  It is attached.  Please 
test it in your environments.  I have tested that it passes the basic 
tls test suite against a threaded Tcl 8.5.7 core build on Linux-x64 (and 
verified that OPENSSL_THREADS was true for this install).


This patch is against tls 1.6 head.

Jeff

On 05/05/2009 3:42 PM, Sep Ng 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  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.



--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to 
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.
? announce.txt
? tls-thread.diff
? tls-verify.diff
Index: Makefile.in
===
RCS file: /cvsroot/tls/tls/Makefile.in,v
retrieving revision 1.27
diff -u -r1.27 Makefile.in
--- Makefile.in 19 Mar 2008 22:57:03 -  1.27
+++ Makefile.in 5 May 2009 23:52:38 -
@@ -205,7 +205,7 @@
  file copy [file join $(srcdir) tls.tcl] tls.tcl \
  } ;\
  source [file join $(srcdir) tls.tcl]; \
- set argv $(TESTFLAGS); \
+ set argv {$(TESTFLAGS)}; \
  source [file join $(srcdir) tests all.tcl]" | $(TCLSH)
 
 shell: binaries libraries
Index: tls.c
===
RCS file: /cvsroot/tls/tls/tls.c,v
retrieving revision 1.30
diff -u -r1.30 tls.c
--- tls.c   19 Mar 2008 22:06:13 -  1.30
+++ tls.c   5 May 2009 23:52:38 -
@@ -130,6 +130,46 @@
 #define sk_SSL_CIPHER_value( sk, index)(SSL_CIPHER*)sk_value((sk), 
(index))
 #endif
 
+/*
+ * Thread-Safe TLS Code
+ */
+
+#ifdef TCL_THREADS
+#define OPENSSL_THREAD_DEFINES
+#include 
+
+#ifdef OPENSSL_THREADS
+#include 
+
+/*
+ * Threaded operation requires locking callbacks
+ * Based from /crypto/cryptlib.c of OpenSSL and NSOpenSSL.
+ */
+
+static Tcl_Mutex locks[CRYPTO_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 (mode & CRYPTO_LOCK) {
+   Tcl_MutexLock(&locks[n]);
+} else {
+   Tcl_MutexUnlock(&locks[n]);
+}
+}
+
+static unsigned long
+CryptoThreadIdCallback(void)
+{
+return (unsigned long) Tcl_GetCurrentThread();
+}
+#endif /* OPENSSL_THREADS */
+#endif /* TCL_THREADS */
+
 
 /*
  *---
@@ -1468,6 +1508,9 @@
 {
 int major, minor, patchlevel, release, i;
 char rnd_seed[16] = "GrzSlplKqUdnnzP!";/* 16 bytes */
+#if defined(OPENSSL_THREADS) && defined(TCL_THREADS)
+size_t num_locks;
+#endif
 
 /*
  * The original 8.2.0 stacked channel implementation (and the patch
@@ -1500,6 +1543,24 @@
channelTypeVersion = TLS_CHANNEL_VERSION_1;
 }
 
+if (CRYPTO_set_mem_functions((void *(*)(size_t))Tcl_Alloc,
+   (void *(*)(void *, size_t))Tcl_Realloc,
+   (void(*)(void *))Tcl_Free) == 0) {
+   /* Not using Tcl's mem functions ... not critical */
+}
+
+#if defined(OPENSSL_THREADS) && defined(TCL_THREADS)
+/* should we consider allocating mutexes? */
+num_locks = CRYPTO_num_locks();
+if (num_locks > CRYPTO_NUM_LOCKS) {
+   Tcl_AppendResult(interp, "crypto num locks size error", NULL);
+   return TCL_ERROR;
+}
+
+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;


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to 
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Sep Ng]

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  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  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.0 +0800
> > > +++ tls.c  2009-05-05 15:41:16.0 +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 
> > > +
> > > +#if defined(OPENSSL_THREADS)
> > > +
> > > +#include 
> > > +
> > > +/*
> > > + * 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 
> > >  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 
> >  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 
>  with the
> body of "SIGNOFF AOL

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Sep Ng]

I just tried your patch, Jeff.  It still crashes.  I'll try to get a
backtrace right now.

On May 6, 7:53 am, Jeff Hobbs  wrote:
> Of the presented patches, I didn't find one that seemed to actually
> work, so I wrote one based on those presented.  It is attached.  Please
> test it in your environments.  I have tested that it passes the basic
> tls test suite against a threaded Tcl 8.5.7 core build on Linux-x64 (and
> verified that OPENSSL_THREADS was true for this install).
>
> This patch is against tls 1.6 head.
>
> Jeff
>
> On 05/05/2009 3:42 PM, Sep Ng 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  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.
>
> --
> AOLserver -http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to 
>  with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
> field of your email blank.
>
> [tls-thread.diff3K ]? announce.txt
> ? tls-thread.diff
> ? tls-verify.diff
> Index: Makefile.in
> ===
> RCS file: /cvsroot/tls/tls/Makefile.in,v
> retrieving revision 1.27
> diff -u -r1.27 Makefile.in
> --- Makefile.in 19 Mar 2008 22:57:03 -  1.27
> +++ Makefile.in 5 May 2009 23:52:38 -
> @@ -205,7 +205,7 @@
>   file copy [file join $(srcdir) tls.tcl] tls.tcl \
>   } ;\
>   source [file join $(srcdir) tls.tcl]; \
> - set argv $(TESTFLAGS); \
> + set argv {$(TESTFLAGS)}; \
>   source [file join $(srcdir) tests all.tcl]" | $(TCLSH)
>
>  shell: binaries libraries
> Index: tls.c
> ===
> RCS file: /cvsroot/tls/tls/tls.c,v
> retrieving revision 1.30
> diff -u -r1.30 tls.c
> --- tls.c   19 Mar 2008 22:06:13 -  1.30
> +++ tls.c   5 May 2009 23:52:38 -
> @@ -130,6 +130,46 @@
>  #define sk_SSL_CIPHER_value( sk, index)(SSL_CIPHER*)sk_value((sk), 
> (index))
>  #endif
>
> +/*
> + * Thread-Safe TLS Code
> + */
> +
> +#ifdef TCL_THREADS
> +#define OPENSSL_THREAD_DEFINES
> +#include 
> +
> +#ifdef OPENSSL_THREADS
> +#include 
> +
> +/*
> + * Threaded operation requires locking callbacks
> + * Based from /crypto/cryptlib.c of OpenSSL and NSOpenSSL.
> + */
> +
> +static Tcl_Mutex locks[CRYPTO_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 (mode & CRYPTO_LOCK) {
> +   Tcl_MutexLock(&locks[n]);
> +} else {
> +   Tcl_MutexUnlock(&locks[n]);
> +}
> +}
> +
> +static unsigned long
> +CryptoThreadIdCallback(void)
> +{
> +return (unsigned long) Tcl_GetCurrentThread();
> +}
> +#endif /* OPENSSL_THREADS */
> +#endif /* TCL_THREADS */
> +
>
>  /*
>   *---
> @@ -1468,6 +1508,9 @@
>  {
>  int major, minor, patchlevel, release, i;
>  char rnd_seed[16] = "GrzSlplKqUdnnzP!";  /* 16 bytes */
> +#if defined(OPENSSL_THREADS) && defined(TCL_THREADS)
> +size_t num_locks;
> +#endif
>
>  /*
>   * The original 8.2.0 stacked channel implementation (and the patch
> @@ -1500,6 +1543,24 @@
> channelTypeVersion = TLS_CHANNEL_VERSION_1;
>  }
>
> +if (CRYPTO_set_mem_functions((void *(*)(size_t))Tcl_Alloc,
> +   (void *(*)(void *, size_t))Tcl_Realloc,
> +   (void(*)(void *))Tcl_Free) == 0) {
> +   /* Not using Tcl's mem functions ... not critical */
> +}
> +
> +#if defined(OPENSSL_THREADS) && defined(TCL_THREADS)
> +/* should we consider allocating mutexes? */
> +num_locks = CRYPTO_num_locks();
> +if (num_locks > CRYPTO_NUM_LOCKS) {
> +   Tcl_AppendResult(interp, "crypto num locks size error", NULL);
> +   return TCL_ERROR;
> +}
> +
> +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;
>
> --
> AOLserver -http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to 
>  with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
> field of your email blank.


--
AO

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Jack Schmidt]

I've just yanked the debug.  This includes the backtrace and memory frame
info and the local info for most of the frames up until #11 CTX_Init.  As
before, the crash happens when DH_free is called.

2009/5/6 Jeff Hobbs 

> Of the presented patches, I didn't find one that seemed to actually work,
> so I wrote one based on those presented.  It is attached.  Please test it in
> your environments.  I have tested that it passes the basic tls test suite
> against a threaded Tcl 8.5.7 core build on Linux-x64 (and verified that
> OPENSSL_THREADS was true for this install).
>
> This patch is against tls 1.6 head.
>
> Jeff
>
> On 05/05/2009 3:42 PM, Sep Ng 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  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.
>>>
>>
>
> --
> 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.
>
> ? announce.txt
> ? tls-thread.diff
> ? tls-verify.diff
> Index: Makefile.in
> ===
> RCS file: /cvsroot/tls/tls/Makefile.in,v
> retrieving revision 1.27
> diff -u -r1.27 Makefile.in
> --- Makefile.in 19 Mar 2008 22:57:03 -  1.27
> +++ Makefile.in 5 May 2009 23:52:38 -
> @@ -205,7 +205,7 @@
>  file copy [file join $(srcdir) tls.tcl] tls.tcl \
>  } ;\
>  source [file join $(srcdir) tls.tcl]; \
> - set argv $(TESTFLAGS); \
> + set argv {$(TESTFLAGS)}; \
>  source [file join $(srcdir) tests all.tcl]" | $(TCLSH)
>
>  shell: binaries libraries
> Index: tls.c
> ===
> RCS file: /cvsroot/tls/tls/tls.c,v
> retrieving revision 1.30
> diff -u -r1.30 tls.c
> --- tls.c   19 Mar 2008 22:06:13 -  1.30
> +++ tls.c   5 May 2009 23:52:38 -
> @@ -130,6 +130,46 @@
>  #define sk_SSL_CIPHER_value( sk, index)(SSL_CIPHER*)sk_value((sk),
> (index))
>  #endif
>
> +/*
> + * Thread-Safe TLS Code
> + */
> +
> +#ifdef TCL_THREADS
> +#define OPENSSL_THREAD_DEFINES
> +#include 
> +
> +#ifdef OPENSSL_THREADS
> +#include 
> +
> +/*
> + * Threaded operation requires locking callbacks
> + * Based from /crypto/cryptlib.c of OpenSSL and NSOpenSSL.
> + */
> +
> +static Tcl_Mutex locks[CRYPTO_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 (mode & CRYPTO_LOCK) {
> +   Tcl_MutexLock(&locks[n]);
> +} else {
> +   Tcl_MutexUnlock(&locks[n]);
> +}
> +}
> +
> +static unsigned long
> +CryptoThreadIdCallback(void)
> +{
> +return (unsigned long) Tcl_GetCurrentThread();
> +}
> +#endif /* OPENSSL_THREADS */
> +#endif /* TCL_THREADS */
> +
>
>  /*
>  *---
> @@ -1468,6 +1508,9 @@
>  {
> int major, minor, patchlevel, release, i;
> char rnd_seed[16] = "GrzSlplKqUdnnzP!";/* 16 bytes */
> +#if defined(OPENSSL_THREADS) && defined(TCL_THREADS)
> +size_t num_locks;
> +#endif
>
> /*
>  * The original 8.2.0 stacked channel implementation (and the patch
> @@ -1500,6 +1543,24 @@
>channelTypeVersion = TLS_CHANNEL_VERSION_1;
> }
>
> +if (CRYPTO_set_mem_functions((void *(*)(size_t))Tcl_Alloc,
> +   (void *(*)(void *, size_t))Tcl_Realloc,
> +   (void(*)(void *))Tcl_Free) == 0) {
> +   /* Not using Tcl's mem functions ... not critical */
> +}
> +
> +#if defined(OPENSSL_THREADS) && defined(TCL_THREADS)
> +/* should we consider allocating mutexes? */
> +num_locks = CRYPTO_num_locks();
> +if (num_locks > CRYPTO_NUM_LOCKS) {
> +   Tcl_AppendResult(interp, "crypto num locks size error", NULL);
> +   return TCL_ERROR;
> +}
> +
> +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;
>
>
> --
> AOLserver - http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to <
> lists...@listserv.aol.com> with

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Sep Ng]

Hi Jeff,

I took a closer look at the patch you posted.  It seems that the
CRYPTO_set_mem_functions is not succeeding.  The default memory
functions that CRYPTO uses are malloc, realloc, and free but from the
back trace, it looks like ns_malloc, ns_realloc and ns_free are the
ones being used for some reason.  I think I'm running out of ideas
here.  It's unclear why CRYPTO_set_mem_function would return 0 instead
of 1, unless it's some bug in my OpenSSL package in Ubuntu.

On May 6, 8:42 am, Jack Schmidt  wrote:
> I've just yanked the debug.  This includes the backtrace and memory frame
> info and the local info for most of the frames up until #11 CTX_Init.  As
> before, the crash happens when DH_free is called.
>
> 2009/5/6 Jeff Hobbs 
>
>
>
> > Of the presented patches, I didn't find one that seemed to actually work,
> > so I wrote one based on those presented.  It is attached.  Please test it in
> > your environments.  I have tested that it passes the basic tls test suite
> > against a threaded Tcl 8.5.7 core build on Linux-x64 (and verified that
> > OPENSSL_THREADS was true for this install).
>
> > This patch is against tls 1.6 head.
>
> > Jeff
>
> > On 05/05/2009 3:42 PM, Sep Ng 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  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.
>
> > --
> > 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.
>
> > ? announce.txt
> > ? tls-thread.diff
> > ? tls-verify.diff
> > Index: Makefile.in
> > ===
> > RCS file: /cvsroot/tls/tls/Makefile.in,v
> > retrieving revision 1.27
> > diff -u -r1.27 Makefile.in
> > --- Makefile.in 19 Mar 2008 22:57:03 -  1.27
> > +++ Makefile.in 5 May 2009 23:52:38 -
> > @@ -205,7 +205,7 @@
> >  file copy [file join $(srcdir) tls.tcl] tls.tcl \
> >  } ;\
> >  source [file join $(srcdir) tls.tcl]; \
> > - set argv $(TESTFLAGS); \
> > + set argv {$(TESTFLAGS)}; \
> >  source [file join $(srcdir) tests all.tcl]" | $(TCLSH)
>
> >  shell: binaries libraries
> > Index: tls.c
> > ===
> > RCS file: /cvsroot/tls/tls/tls.c,v
> > retrieving revision 1.30
> > diff -u -r1.30 tls.c
> > --- tls.c   19 Mar 2008 22:06:13 -  1.30
> > +++ tls.c   5 May 2009 23:52:38 -
> > @@ -130,6 +130,46 @@
> >  #define sk_SSL_CIPHER_value( sk, index)(SSL_CIPHER*)sk_value((sk),
> > (index))
> >  #endif
>
> > +/*
> > + * Thread-Safe TLS Code
> > + */
> > +
> > +#ifdef TCL_THREADS
> > +#define OPENSSL_THREAD_DEFINES
> > +#include 
> > +
> > +#ifdef OPENSSL_THREADS
> > +#include 
> > +
> > +/*
> > + * Threaded operation requires locking callbacks
> > + * Based from /crypto/cryptlib.c of OpenSSL and NSOpenSSL.
> > + */
> > +
> > +static Tcl_Mutex locks[CRYPTO_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 (mode & CRYPTO_LOCK) {
> > +   Tcl_MutexLock(&locks[n]);
> > +} else {
> > +   Tcl_MutexUnlock(&locks[n]);
> > +}
> > +}
> > +
> > +static unsigned long
> > +CryptoThreadIdCallback(void)
> > +{
> > +return (unsigned long) Tcl_GetCurrentThread();
> > +}
> > +#endif /* OPENSSL_THREADS */
> > +#endif /* TCL_THREADS */
> > +
>
> >  /*
> >  *---
> > @@ -1468,6 +1508,9 @@
> >  {
> > int major, minor, patchlevel, release, i;
> > char rnd_seed[16] = "GrzSlplKqUdnnzP!";/* 16 bytes */
> > +#if defined(OPENSSL_THREADS) && defined(TCL_THREADS)
> > +size_t num_locks;
> > +#endif
>
> > /*
> >  * The original 8.2.0 stacked channel implementation (and the patch
> > @@ -1500,6 +1543,24 @@
> >channelTypeVersion = TLS_CHANNEL_VERSION_1;
> > }
>
> > +if (CRYPTO_set_mem_functions((void *(*)(size_t))Tcl_Alloc,
> > +   (void *(*)(void *, size_t))Tcl_Realloc,
> > +   (void(*)(void *))Tcl_Free) == 0) {
> > +   /* Not using Tcl's mem functions ... not critical *

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Jeff Hobbs]

Is it possible that both nsopenssl and tls are in use, and that they 
both might be initializing openssl in the same process?  I'm not sure if 
this would be a support case if so.


On 05/05/2009 6:16 PM, Sep Ng wrote:

Hi Jeff,

I took a closer look at the patch you posted.  It seems that the
CRYPTO_set_mem_functions is not succeeding.  The default memory
functions that CRYPTO uses are malloc, realloc, and free but from the
back trace, it looks like ns_malloc, ns_realloc and ns_free are the
ones being used for some reason.  I think I'm running out of ideas
here.  It's unclear why CRYPTO_set_mem_function would return 0 instead
of 1, unless it's some bug in my OpenSSL package in Ubuntu.

On May 6, 8:42 am, Jack Schmidt  wrote:

I've just yanked the debug.  This includes the backtrace and memory frame
info and the local info for most of the frames up until #11 CTX_Init.  As
before, the crash happens when DH_free is called.

2009/5/6 Jeff Hobbs 




Of the presented patches, I didn't find one that seemed to actually work,
so I wrote one based on those presented.  It is attached.  Please test it in
your environments.  I have tested that it passes the basic tls test suite
against a threaded Tcl 8.5.7 core build on Linux-x64 (and verified that
OPENSSL_THREADS was true for this install).
This patch is against tls 1.6 head.
Jeff
On 05/05/2009 3:42 PM, Sep Ng 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  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.




--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to 
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Sep Ng]

I think I understand where you're going with that.  But, I don't think
OpenSSL checks if it has been set already.

int CRYPTO_set_mem_functions(void *(*m)(size_t), void *(*r)(void *,
size_t),
void (*f)(void *))
{
if (!allow_customize)
return 0;
if ((m == 0) || (r == 0) || (f == 0))
return 0;
malloc_func=m; malloc_ex_func=default_malloc_ex;
realloc_func=r; realloc_ex_func=default_realloc_ex;
free_func=f;
malloc_locked_func=m;
malloc_locked_ex_func=default_malloc_locked_ex;
free_locked_func=f;
return 1;
}

I know that allow_customize is always 1 and that the only other check
that happens is if one of the three functions in the
CRYPTO_set_mem_functions parameters was left at zero (NULL?).  I do
suppose it is worth a try to test aolserver without nsopenssl, if the
results differ.  It's equally strange that setting -DNO_DH=1 would
allow the entire setup (aolserver+nsopenssl+tls) to function without
crashing.

I will try and test aolserver without ssl and post back my results.

On May 7, 12:13 am, Jeff Hobbs  wrote:
> Is it possible that both nsopenssl and tls are in use, and that they
> both might be initializing openssl in the same process?  I'm not sure if
> this would be a support case if so.
>
> On 05/05/2009 6:16 PM, Sep Ng wrote:
>
> > Hi Jeff,
>
> > I took a closer look at the patch you posted.  It seems that the
> > CRYPTO_set_mem_functions is not succeeding.  The default memory
> > functions that CRYPTO uses are malloc, realloc, and free but from the
> > back trace, it looks like ns_malloc, ns_realloc and ns_free are the
> > ones being used for some reason.  I think I'm running out of ideas
> > here.  It's unclear why CRYPTO_set_mem_function would return 0 instead
> > of 1, unless it's some bug in my OpenSSL package in Ubuntu.
>
> > On May 6, 8:42 am, Jack Schmidt  wrote:
> >> I've just yanked the debug.  This includes the backtrace and memory frame
> >> info and the local info for most of the frames up until #11 CTX_Init.  As
> >> before, the crash happens when DH_free is called.
>
> >> 2009/5/6 Jeff Hobbs 
>
> >>> Of the presented patches, I didn't find one that seemed to actually work,
> >>> so I wrote one based on those presented.  It is attached.  Please test it 
> >>> in
> >>> your environments.  I have tested that it passes the basic tls test suite
> >>> against a threaded Tcl 8.5.7 core build on Linux-x64 (and verified that
> >>> OPENSSL_THREADS was true for this install).
> >>> This patch is against tls 1.6 head.
> >>> Jeff
> >>> On 05/05/2009 3:42 PM, Sep Ng 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  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.
>
> 
>
> --
> AOLserver -http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to 
>  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 
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Jack Schmidt]

Hi, Sep here.

I just tried by disabling nsopenssl and it crashes at the same point.  I
suppose this is definitely more related to using aolserver with tls.  I've
included a backtrace and it shows the same point of failure.

We use aolserver 4.0.10, though I'm not sure how relevant it is to the
discussion.  I'll try to check the startup routine of aolserver and see if I
can find anything.

2009/5/7 Jeff Hobbs 

> Is it possible that both nsopenssl and tls are in use, and that they both
> might be initializing openssl in the same process?  I'm not sure if this
> would be a support case if so.
>
>
> On 05/05/2009 6:16 PM, Sep Ng wrote:
>
>> Hi Jeff,
>>
>> I took a closer look at the patch you posted.  It seems that the
>> CRYPTO_set_mem_functions is not succeeding.  The default memory
>> functions that CRYPTO uses are malloc, realloc, and free but from the
>> back trace, it looks like ns_malloc, ns_realloc and ns_free are the
>> ones being used for some reason.  I think I'm running out of ideas
>> here.  It's unclear why CRYPTO_set_mem_function would return 0 instead
>> of 1, unless it's some bug in my OpenSSL package in Ubuntu.
>>
>> On May 6, 8:42 am, Jack Schmidt  wrote:
>>
>>> I've just yanked the debug.  This includes the backtrace and memory frame
>>> info and the local info for most of the frames up until #11 CTX_Init.  As
>>> before, the crash happens when DH_free is called.
>>>
>>> 2009/5/6 Jeff Hobbs 
>>>
>>>
>>>
>>>  Of the presented patches, I didn't find one that seemed to actually
 work,
 so I wrote one based on those presented.  It is attached.  Please test
 it in
 your environments.  I have tested that it passes the basic tls test
 suite
 against a threaded Tcl 8.5.7 core build on Linux-x64 (and verified that
 OPENSSL_THREADS was true for this install).
 This patch is against tls 1.6 head.
 Jeff
 On 05/05/2009 3:42 PM, Sep Ng 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  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.
>>
>
>
>
> --
> 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.
>



-- 
"A scrum a day keeps the pigs at bay"


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to 
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.


bt-without-nsopenssl
Description: Binary data

Re: [AOLSERVER] Fwd: [AOLSERVER] TLS 1.6 and Aolserver

[Sep Ng]

Hi Jeff,

I'm going to review options on how to progress with this problem with
Jade.  I've traced and stepped into TlsInit, and CtxInit functions and
as far as I can see, the mutex functions we wrote seems to be
working.  I wonder if there is some influence by aolserver or what
not.  I don't know.  It also seems that allow_customize in
CRYPTO_set_mem_functions is getting set to zero for some reason.  I'm
not totally sure why that is happening.

At this moment, I don't know what to do.

On May 7, 7:14 am, Jack Schmidt  wrote:
> Hi, Sep here.
>
> I just tried by disabling nsopenssl and it crashes at the same point.  I
> suppose this is definitely more related to using aolserver with tls.  I've
> included a backtrace and it shows the same point of failure.
>
> We use aolserver 4.0.10, though I'm not sure how relevant it is to the
> discussion.  I'll try to check the startup routine of aolserver and see if I
> can find anything.
>
> 2009/5/7 Jeff Hobbs 
>
>
>
> > Is it possible that both nsopenssl and tls are in use, and that they both
> > might be initializing openssl in the same process?  I'm not sure if this
> > would be a support case if so.
>
> > On 05/05/2009 6:16 PM, Sep Ng wrote:
>
> >> Hi Jeff,
>
> >> I took a closer look at the patch you posted.  It seems that the
> >> CRYPTO_set_mem_functions is not succeeding.  The default memory
> >> functions that CRYPTO uses are malloc, realloc, and free but from the
> >> back trace, it looks like ns_malloc, ns_realloc and ns_free are the
> >> ones being used for some reason.  I think I'm running out of ideas
> >> here.  It's unclear why CRYPTO_set_mem_function would return 0 instead
> >> of 1, unless it's some bug in my OpenSSL package in Ubuntu.
>
> >> On May 6, 8:42 am, Jack Schmidt  wrote:
>
> >>> I've just yanked the debug.  This includes the backtrace and memory frame
> >>> info and the local info for most of the frames up until #11 CTX_Init.  As
> >>> before, the crash happens when DH_free is called.
>
> >>> 2009/5/6 Jeff Hobbs 
>
> >>>  Of the presented patches, I didn't find one that seemed to actually
>  work,
>  so I wrote one based on those presented.  It is attached.  Please test
>  it in
>  your environments.  I have tested that it passes the basic tls test
>  suite
>  against a threaded Tcl 8.5.7 core build on Linux-x64 (and verified that
>  OPENSSL_THREADS was true for this install).
>  This patch is against tls 1.6 head.
>  Jeff
>  On 05/05/2009 3:42 PM, Sep Ng 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  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.
>
> >
>
> > --
> > 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.
>
> --
> "A scrum a day keeps the pigs at bay"
>
> --
> AOLserver -http://www.aolserver.com/
>
> To Remove yourself from this list, simply send an email to 
>  with the
> body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
> field of your email blank.
>
>  bt-without-nsopenssl
> 17KViewDownload


--
AOLserver - http://www.aolserver.com/

To Remove yourself from this list, simply send an email to 
 with the
body of "SIGNOFF AOLSERVER" in the email message. You can leave the Subject: 
field of your email blank.