curl / Mailing Lists / curl-library / Single Mail


Re: Application Crashes during curl_multi_perform

From: Ray Satiro <>
Date: Tue, 10 Apr 2018 22:57:04 -0400

On 4/10/2018 1:05 PM, Rich Mpanga wrote:
> We have been running to this problem recently lately with MacOs High
> Sierra and I haven't found any good  discussions about it. We have a
> Google drive like Application that syncs files to and from clients and
> a server. The application is multi-threaded and we reuse curl handles,
> meaning that once a thread is done with a request it places the handle
> into a queue. Each thread has its own curl and multi handle. 
> I managed to create a simple C++ program that reproduces the crash.
> The crash report and program are attached. The crash happens when 2 or
> more threads call curl_multi_perform at the same time.  As of right
> now the only way I been able to prevent the crash is to force each
> thread to create a new curl handle. 
> I also implemented the crypto locking callbacks in this example:
> These functions do not appear to be called and the crash still occurs. 
> Apple did make a lot of changes to their Openssl libraries. They moved
> from Openssl to Libressl and probably made some changes to the code base.
> I have a few questions,
> 1. Are there other workarounds other than recreating the curl handle ?
> 2. What are the performance impacts from creating a new curl handle
> for similar requests ?
> 3. Are the threading callback functions deprecated ? 

I tried this in Ubuntu but I didn't get a crash. I changed the host from to a local https server so I didn't inadvertently DoS Daniel. My
curl_version() is:

libcurl/7.59.0 OpenSSL/1.0.2n zlib/1.2.8 nghttp2/1.31.0 librtmp/2.3

Most of the thread related crashes that are reported are not due to bugs
in libcurl but rather due to failure to follow thread safety guidelines.
Please review

Often it's as simple as CURLOPT_NOSIGNAL, 1L

In your code I see you aren't calling curl_multi_remove_handle before
curl_multi_cleanup as documented [1]. Without that there's a lot of this:

* Internal error removing splay node = 1

(I actually thought we had code to auto remove the handles if the user
forgot but I may be remembering that wrong.)

Also I see in grabHandle you aren't unlocking before return when refresh
is true so that also needs to be fixed but is unrelated.

Try adding nosignal and calling remove_handle and see what happens. Try
limiting threads to 1 thread and see what happens. And in your reply
please us your curl_version()


Received on 2018-04-11