Hi Daniel

Well I cross checked your codebase and found curl_threads.h

In here you are defining curl_mutex_t as pthread_mutex for posix complaint
platforms and CRITICAL_SECTION object for windows. So this entails that
curl will be using these libraries for any critical sections inside their
code. This also means curl is forcing pthread on nix platforms even when
native libraries might outperform it. (I am guessing optimized thread
safety is a concern here).

Now my concern is the following:-

Assume that there is a user who is not proficient in c and does not dabble
with curl source code and just builds curl with openssl. They will find
intermittent crashes on different platforms due to openssl not being thread
safe and might lose patience and stop using curl all together.

Is it not a viable idea that the callback handlers to openssl use
curl_mutex_t and its acquire and release method to ensure out of the box
functionality for curl?

An explanation for your apprehension in adding the callback handlers in
cURL could be the fact that you do not wish to override existing callback
support in the app which uses curl(for example application might use curl
and openssl directly as well in which case your implementation can override
its default behaviour). However IMO pthreads is quite standardized and at
the very least nix platforms can use it while windows can stick to their
implementation. I believe its a justifiable reason to implement callbacks
in your layer.

Yours sincerely
Arunav Sanyal

On Mon, Feb 10, 2014 at 11:33 AM, Arunav Sanyal
<arunav.sanyal91_at_gmail.com>wrote:

> Hi
>
> Openssl is crashing within calls of libcurl. The stack trace for your
> reference. :-
>
> sha1-ppc.sha1_block_data_order(??, ??, ??) at 0x9000000125e2b34
> sha1dgst.SHA1_Update_at_AF7_3() at 0x9000000125e29f0
> m_sha1.update() at 0x9000000125de250
> digest.EVP_DigestUpdate() at 0x9000000125d7504
> md_rand.ssleay_rand_bytes() at 0x900000012695da4
> rand_lib.RAND_bytes() at 0x9000000125c4910
> rsa_pk1.RSA_padding_add_PKCS1_type_2() at 0x90000001262238c
> rsa_eay.RSA_eay_public_encrypt() at 0x900000012620bc8
> rsa_crpt.RSA_public_encrypt() at 0x9000000125e4d90
> s3_clnt.ssl3_send_client_key_exchange() at 0x90000001286589c
> s3_clnt.ssl3_connect() at 0x900000012869620
> ssl_lib.SSL_connect() at 0x90000001282ede0
> s23_clnt.ssl23_get_server_hello() at 0x900000012874c58
> s23_clnt.ssl23_connect() at 0x900000012875c58
> ssl_lib.SSL_connect() at 0x90000001282ede0
> ossl_connect_step2() at 0x900000013de7dac
> ossl_connect_common() at 0x900000013de59f0
> Curl_ssl_connect_nonblocking() at 0x900000013de48e0
> https_connecting() at 0x900000013dff89c
> Curl_protocol_connecting_at_AF71_46() at 0x900000013de3ab4
> multi_runsingle() at 0x900000013dd36a4
> curl_multi_perform() at 0x900000013dd5cc4
> curl_easy_perform() at 0x900000013e325ec
>
> I am using CURLOPT_NOSIGNAL option as true. No I tried to look for some
> answers and found this thread(namely locking_function and threadid_func
> ):-
>
> http://curl.haxx.se/docs/faq.html#Is_libcurl_thread_safe
>
> This gives pointers to examples in Solaris and Win32 examples for certain
> callback handlers needed for correct thread safe usage.
>
> Now I didnt browse through curl source but I believe that these callback
> handlers must be implemented in curl_global_init(). Is there any other
> location I should put these handlers(I mean write the implementation
> somewhere?). More importantly, I don't quite understand why curl didn't
> handle this in their baseline implementation?
>
>
> Yours sincerely
>
>
> --
> Arunav Sanyal
> Graduate student
> B.E (Hons) Computer Science
> BITS Pilani K.K Birla Goa Campus
>
> Software Engineer
> INFORMATICA BUSINESS SOLUTIONS
>
>

-- 
Arunav Sanyal
Graduate student
B.E (Hons) Computer Science
BITS Pilani K.K Birla Goa Campus
Software Engineer
INFORMATICA BUSINESS SOLUTIONS

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-02-10