libct ct_connect thread_safe

Mitch Freed <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <[email protected]>
Is ct_connect (libct) not thread-safe? It looks like it's calling 
tds_init_openssl at some point down the line which calls 
SSL_library_init. I don't see any checks in place to prevent multiple 
threads from calling SSL_library_init (tds/net.c) rather than 
SSL_library_init only being called once by the first thread that sees 
it's not initialized.

I have seen the FAQ indicating that the threads cannot share a 
CS_CONNECTION, which they do not in my case.

I'm getting a SIGABRT with a large stack trace that ends like this:

#39 0xf7f3e9f2 in SSL_library_init () from /usr/lib/libssl.so.0.9.8
#40 0xf7f421a1 in ?? () from /usr/lib/libssl.so.0.9.8
#41 0x0000001d in ?? ()
#42 0xf7f3e907 in SSL_library_init () from /usr/lib/libssl.so.0.9.8
#43 0xf7f865bb in tds_init_openssl () from /usr/lib/libct.so.4
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

If I use a mutex in my code around the call to ct_connect I am able to 
prevent the SIGABRT.

Thanks,
Mitch
This e-mail message and any attachments contain information that is confidential and may be privileged.  If the reader of this e-mail is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited.  If you have received this communication in error, please immediately notify us by replying to this message or by sending an email to [email protected], and destroy all copies of this message and any attachments without reading or disclosing them.  Thank you.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.