cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Crash in curl_hash_add in iOS

From: JOHAN LANTZ <johan.lantz_at_telefonica.com>
Date: Fri, 1 Jul 2016 17:31:40 +0000

Hi again

I have now simplified how we interact with curl so it is only started and stopped once in the whole application lifecycle. This means it should be guaranteed there is only one single worker polling curl_multi_perform and nothing else.

I have also recompiled using -O0 instead of -Os. Would this be enough? It is probably possible to add -g as well if that would help so I am awaiting your confirmation on if that is necessary.

The numbers of crashes are growing rapidly in Crashlytics so I am quite concerned. The common entry point is always curl_multi_perform but then it crashes in various places the top ones being: curl_hash_add, curl_connecthost, darwinssl_connect_step2, curl_hostcache_prune, curl_disconnect, create_conn, darwin_ssl_connect_common.

I understand this is impossible to answer with this little info so all pointers on what do change or add are welcome and I will try to include it in the next release which we will have to make quite soon. I have never managed to make it crash myself and I have been testing a lot.

Thanks in advance

Johan

On 01/07/16 13:44, "JOHAN LANTZ" <johan.lantz_at_telefonica.com> wrote:

>Hi Daniel
>
>As always thanks for taking the time to respond so rapidly.
>
>I completely understand there is little information so let’s start with what we can improve.
>
>1. We are using DarwinSSL
>
>2. I am using this script to build curl:
> <https://github.com/johanlantz/curly/blob/master/third-party/curl/ios/build_libcurl_dist.sh>
>
>
>So, currently -Os is used by default. Would it help if I made the next release with -O0 or -Og?
>
>3. It is not unlikely that there is some clash with threads or mutex. Could you give any indication on what to think about. Is it really necessary to think about the mutexes when using DarwinSSL? Also, in theory I only have one worker thread calling curl_multi_perform:
> <https://github.com/johanlantz/curly/blob/master/curly.c#L413>
>
>But of course it is possible that I am doing something wrong.
>
>4. I am thinking that perhaps I am messing up something when shutting down Curl here:
> <https://github.com/johanlantz/curly/blob/master/curly.c#L84>
>
>
>So that the previous thread is not properly terminated if there is a restart. But I can not find anything obvious right now.
>
>I hope that by starting with understanding these 4 things maybe I will be able to narrow it down a bit.
>
>Thanks again
>
>Johan
>
>>On Thu, 30 Jun 2016, JOHAN LANTZ wrote:
>>
>>>This morning we deployed our first version of an iOS app that relies on curl
>>>(4.47.0) for some of the http functionality.
>>
>>threads + crash = question about TLS mutex use
>>
>>Which TLS backend are you using? Is the mutex situation under control?
>>
>>Any chance you can get a version with debug symbols to crash so that we get
>>more info about the actual situation? Just a stack trace without symbols with
>>no ability to reproduce is really hard to work with.
>>

________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição

-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2016-07-01