On Wed, 19 Feb 2014, Kristoffer Gleditsch wrote:
I've been testing the share objects (CURLSH) for cookie sharing between handles lately, but I've stumbled across a deadlock, so I'm wondering if this is a bug, or if I'm just using it incorrectly:
It certainly sounds like a bug!
We flush the cookie list: curl_easy_setopt(request, CURLOPT_COOKIELIST, "FLUSH"); When executing this, Curl_setopt() does a share_lock on the cookie data (https://github.com/bagder/curl/blob/master/lib/url.c#L1145). Then it calls Curl_flush_cookies(), and that does another share_lock on the cookie data (https://github.com/bagder/curl/blob/master/lib/cookie.c#L1320), which then makes pthreads fall over.
It shouldn't do that. We need to fix. You up to correcting it and sending us a patch?
Is this intentional, i.e. are the lock function given to the share handle required to be recursive? The documentation I've found don't seem to say so, but I may not have looked in the right places.
I guess the docs should explicitly say that it isn't needed. And we should add a test case for your use case here to make sure we don't reintroduce this later...
(Granted, the FLUSH option seems to be a NOP when using the share object instead of a cookie file, so the quick solution for us is to just remove the call.)
Is it? I figure it should flush them from the shared object... Perhaps a second bug?
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
