On Sat, 15 Nov 2008, Daniel Stenberg wrote:

My current suspicion is that the problem is related to libcurl's connection
cache and the fact that both connections are done to the same server.

The connections are considered "done" when the CURLM_STATE_DONE state is
entered, (as the conn->inuse is set FALSE in the ConnectionDone() function)
but the state is then changed to CURLM_STATE_COMPLETED and only then is the
"completed" message sent off etc.

The reason for the timing-depedent nature of this would then be that some
special conditions need to apply for the mixup/confusion to trigger.

Here's a little patch that helps showing what actual connection (struct
pointer) a specific transfer is using:

--- lib/multi.c 30 Oct 2008 13:45:26 -0000 1.187
+++ lib/multi.c 16 Nov 2008 23:55:43 -0000
@@ -238,9 +238,9 @@
      connectindex = easy->easy_conn->connectindex;

    infof(easy->easy_handle,
- "STATE: %s => %s handle %p; (connection #%ld) \n",
+ "STATE: %s => %s handle %p; (connection #%ld, %p) \n",
          statename[oldstate], statename[easy->state],
- (char *)easy, connectindex);
+ (char *)easy, connectindex, easy->easy_conn);
  #endif
    if(state == CURLM_STATE_COMPLETED)
      /* changing to COMPLETED means there's one less easy handle 'alive' */

-- 
  / daniel.haxx.se