On Fri, 1 Jul 2016, JOHAN LANTZ wrote:

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.

If you use -g, your stack traces will get more details so it'll tell you and us more about how the call trace ended up like it did in the time of the crash.

Darwinssl (secure transport) is thread safe so there shouldn't be any known problem related to that.

The fact that it crashes in different places like that I think rather indicates that something is totally messed up, possibly overwriting random memory or something similarly seriously wrong.

I don't know what tooling you have at hand, but a valgrind style tool would be handy. Other than that, try to make an as dumbed-down version as possible of your app that still shows the problems and start sprinkling printf/logging code or something to see if you can narrow things down.

If I were you, I'd also try an as similar app as possible under macos as it might be an easier environment to debug things in if you just manage to trigger the same problem there.

(I'll run off on vacation now for a few weeks ahead so I will be slower at responding for a while.)

--

 / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html

Reply via email to