Skip to Content.
Sympa Menu

freetds - Re: [freetds] libct ct_connect thread_safe

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: mfreed AT nitrosecurity.com, FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] libct ct_connect thread_safe
  • Date: Thu, 15 Dec 2011 14:18:53 +0100

2011/12/15 Mitch Freed <mfreed AT nitrosecurity.com>:
> 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

Assuming that 2 threads allocate a ctlib connection and try to open at
the same time you can have threading problem. In this case
tds_init_openssl is not threadsafe and should be protected by a mutex.

bye
freddy77




Archive powered by MHonArc 2.6.24.

Top of Page