FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

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