libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] unit tests using curl, openssl & multithreading


From: Christian Grothoff
Subject: Re: [libmicrohttpd] unit tests using curl, openssl & multithreading
Date: Mon, 11 Jun 2012 13:26:07 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.4) Gecko/20120510 Icedove/10.0.4

On 06/08/2012 05:32 PM, Cristian Constantin wrote:
> On Thu, Jun 07, 2012 at 02:20:26PM +0200, Christian Grothoff wrote:
> On 06/06/2012 12:27 PM, Cristian Constantin wrote:
> >>> hi!
> >>>
> >>> the file:
> >>>
> >>> libmicrohttpd/src/testcurl/https/tls_multi_thread_mode_test.c
> >>>
> >>> tests multithreading capabilities of libmicrohttpd(+tls) with
> multiple threads
> >>> both on the client and on the server side.
> >>>
> >>> the client side is implemented using curl+openssl. since I am getting
> >>> random crashes in:
> >>>
> >>> sha1_block_data_order () / sha1-x86_64.s (part of openssl)
> >>>
> >>> I am asking myself whether it has to do with (NOT using properly)
> >>> locking. I had a look and the openssl function which is supposed to
> >>> set up the locking callback, CRYPTO_set_locking_callback() is NOT used
> >>> explicitly when setting up curl/openssl.
> >>>
> >>> what do you think?
>
> Might be.  Some consider linking against OpenSSL from GPL/LGPL code to
> be a license violation, so usually MHD is used with libcurl/gnutls (and
> that's how I test).  In either case, as MHD cannot (and should not) know
> about OpenSSL, it is up to the application to do thread-initialization
> for libraries like OpenSSL.  So I suggest you add the respective calls
> to your application and see if that fixes the issues.
>
> > cristian: hi! I have added the mutexes and the callbacks for
> actually using
> > them to lock and unlock resources. I have tested for more than 12 hours
> > and I did not see the crash anylonger; so most likely this was the
> > problem.
>
> > now, as far as I see for properly fixing this, one needs to use
> > some conditional compilation based on which ssl flavor is used:
> > curl+openssl or curl+gnutls. m4/libcurl.m4 defines "LIBCURL_FEATURE_SSL"
> > but does not say which tls library libcurl was linked with...
>
> > let me know your oppinion on this.

I think this might actually be a bug in curl --- we do call
'curl_global_init(CURL_GLOBAL_ALL)' which presumably is supposed to
initialize the SSL subsystem as well. 

As far as the testcase is concerned, the way to fix this would likely be
to call
'curl_version_info' (see
http://curl.haxx.se/libcurl/c/curl_version_info.html) and
evaluate the 'libssh_version' field to determine if OpenSSL is being
used and
then run the lock initialization code.  The tricky bit here is that
'tls_multi_thread_mode_test' itself doesn't link against OpenSSL (and
should not be made to always depend on it).  So
maybe looking up "CRYPTO_set_locking_callback" using 'dlsym' would be a
reasonable hack to do in that case.

As this is a larger hack unsuitable for a simple testcase, I've added
some logic
to disable this test if curl is compiled against OpenSSL in SVN 21879.


Happy hacking!

Christian





reply via email to

[Prev in Thread] Current Thread [Next in Thread]