Skip to Content.
Sympa Menu

freetds - [freetds] libct ct_connect thread_safe

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Mitch Freed <mfreed AT nitrosecurity.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: [freetds] libct ct_connect thread_safe
  • Date: Wed, 14 Dec 2011 16:18:23 -0700

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
postmaster AT nitrosecurity.com, and destroy all copies of this message and any
attachments without reading or disclosing them. Thank you.





Archive powered by MHonArc 2.6.24.

Top of Page