> > The crash occurs when I set the CURL_OPT_CACHE_TIMEOUT to either -1 (cache
> > forever) or 0 (cache disabled). It doesn't seem to matter if
> > CURLOPT_DNS_USE_GLOBAL_CACHE is set or not.
>
>
> First: global cache is badness, don't use that! ;-)
>

Ok.

>
> Thanks for your research on the reasons for your problems. I've done some
> basic attempts with using -1 or 0 on the cache timeout in one of my test
> programs and it worked fine, but I have fixed one pretty serious "inuse"
> counter screw-up in the cache code (and one case of cache timeout -1 not doing
> right) that might be the reason(s) for your problems.
>

Note that I only had trouble when using a multi handle. Easy handle only
transfers with the same options set never crashed.

The circumstances under which I can get it to reliably crash with CACHE_TIMEOUT
set to -1 or 0 are thus:

-- open a multi handle
-- add 4 or 5 easy handles (with CACHE TIMEOUT set to -1 or 0)
-- enter a multi_perform() loop (I don't use fdset at all)
-- each time an easy transfer is completed, remove it from the multi handle and
clean it up
-- add a new easy handle to the multi handle (so it always maintains the same
amount of current transfers)
-- let the loop run until it crashes (usually after about 20 transfers,
although the size and how long the transfers take seems to be a factor -- when
I set up a local server and kept grabbing a tiny file that would transfer very
quickly it would crash sooner)

The other scenario was like this:

-- open a multi handle
-- add 4 or 5 easy handles (with CACHE_TIMEOUT set to -1 or 0)
-- do a multi_perform() loop and complete all transfers, remove & cleanup each
easy handle
-- cleanup the multi handle
-- open a new multi handle and repeat the process -- about 50% of the time it
would crash as I started calling multi_perform() with the new multi handle, but
sometimes it would complete the second set of transfers successfully

>
> So, this bug *might* be fixed in the current dev version. Since you say you
> can't build your own .DLL from this code, I don't know how to verify if this is
> true or not.
>
>

I someone wants to send me a Win32 .dll I'll try it out under the same
circumstances, but everytime I try to deal with C compilers myself (although I
do have MinGW, Borland, & Watcom installed) I get a headache. If all I have to
do is type "make" or something maybe I can handle it...

-- Andy
Received on 2004-02-18