Still no standalone demo, but I have some more details:

- problem doesn't happen if I compile libCurl with WINVER set to
0x0600 (ie targetting Vista, which seems to point to a difference
between POLL_FINE and select)

- by making my app always access the same server (instead of spreading
load over four), I made the bug appear a lot more. Probably
systematically.

- I have one clear case of a query being cancelled before the server
answered and the next query getting the answer from the initial one.
This, together with the previous remark make me think there is some
confusion going on when reusing a connection that was kept alive.
See attached log file:
   look for //*NB: xxx bytes */ comments I have added. The comment
shows the size the file should be
   then follow the log to see the headers we get
   the %p/%p at the start of each line identifies this/easyHandle of
my easy session C++ wrapper.

- I have had another case where something similar happened, except
that the data the second query got wasn't looking like anything (I'm
guessing it is later packets from the cancelled request, but can't
prove it).

Any help appreciated, I'm still having a lot of trouble working my way
into the libCurl code (lots to learn in there...)
Thanks,
J.

On Thu, Feb 14, 2008 at 3:22 PM, jérôme Muffat-Méridol
<jmuffat_at_webphotomag.com> wrote:
> libCurl v7.18.0, using C API, on Windows. (have had problem since v7.16.2)
> I asked a few months ago, but managed to hide the problem and am only
> coming back to it now.
>
> A bit of context:
> I have objects that get created and destroyed based on user navigation.
> On creation, these objects do a GET on an HTTP server, to get a bitmap.
>
> This is done by creating an easy handle and adding it into the curl
> multi object that is managed by the main Window.
> This multi gets updated regularly through WM_TIMER, using the method that calls
> - curl_multi_fdset
> - select
> - curl_multi_perform (until !=CURLM_CALL_MULTI_PERFORM)
>
> If one of my objects is destroyed while downloading, it attempts to
> cancel it by calling:
> - curl_multi_remove_handle (which seems to do the actual cancelling)
> - curl_easy_cleanup
>
> This works well, except in one case : if I cancel a request between
> the time it was sent to the HTTP server and the time we have received
> something back.
>
> I'm getting a failf(data, "Empty reply from server");
> in Curl_http_done (because readbytecount==0, headerbytecount==0 and
> deductheadercount==0)
> coming from the call "conn->handler->done" in Curl_done
> coming from curl_multi_remove_handle
>
> Once this happens, I'm not sure what is really going on, but I looks
> like data from the cancelled request is received by another one of my
> requests.
> It's quite hard to track because as requests are cancelled, new ones
> get created and they're all concerning just four servers in total...
>
> Sidenote: if the lib is compiled
>
> I'm trying to figure out a way to do a contained test program that
> would have the problem, so I could share the source, but it's taking
> time.
>
> So, in the meantime, does anyone know how bad this failf is ?
> ___________________________________________
> Jérôme Muffat-Méridol - www.gpuViewer.com
>

-- 
___________________________________________
Jérôme Muffat-Méridol - www.gpuViewer.com