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