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 <[email protected]>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@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@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
