> > The problems still remain, but I noticed a valgrind error.
>
> I haven't yet taken a look at your test app but I noticed I can get
valgrind
> reports on the test program I got from you before, only slightly
modified. See
> attachment.
>
> Ravi, any comment on this?

What you mentioned is indeed correct. The problem is really that we're
not clearing a connection's send and recv pipe correctly in the case
that a pipe breaks. The code at the top of multi_runsingle should really
read like this:

RCS file: /cvsroot/curl/curl/lib/multi.c,v
retrieving revision 1.105
diff -u -r1.105 multi.c
--- multi.c 16 Sep 2006 21:50:29 -0000 1.105
+++ multi.c 18 Sep 2006 18:09:59 -0000
@@ -732,6 +732,11 @@
         multistate(easy, CURLM_STATE_COMPLETED);
       }
 
+ Curl_removeHandleFromPipeline(easy->easy_handle,
+ easy->easy_conn->send_pipe);
+ Curl_removeHandleFromPipeline(easy->easy_handle,
+ easy->easy_conn->recv_pipe);
+
       easy->easy_handle->state.pipe_broke = FALSE;
       easy->easy_conn = NULL;
       break;

Unless you prefer just clearing the send and recv pipes unconditionally
when a handle reaches the COMPLETED state.

> ==5980== Invalid write of size 1
> ==5980== at 0x80584A5: signalPipeClose (url.c:1867)
> ==5980== by 0x8058332: Curl_disconnect (url.c:1772)
> ==5980== by 0x80588DB: ConnectionKillOne (url.c:2047)
> ==5980== by 0x805898C: ConnectionStore (url.c:2087)
> ==5980== by 0x805C362: CreateConnection (url.c:4068)
> ==5980== by 0x805C9F6: Curl_connect (url.c:4342)
> ==5980== by 0x804E19F: multi_runsingle (multi.c:792)
> ==5980== by 0x804EF1B: curl_multi_perform (multi.c:1254)
> ==5980== by 0x804B902: main (debugit.c:115)
> ==5980== Address 0x4363DAA is 34,042 bytes inside a block of size
34,112
> free'd==5980== at 0x401C139: free (vg_replace_malloc.c:233)
> ==5980== by 0x804CABC: curl_dofree (memdebug.c:227)
> ==5980== by 0x8055CBD: Curl_close (url.c:322)
> ==5980== by 0x804BF6B: curl_easy_cleanup (easy.c:494)
> ==5980== by 0x804BB87: main (debugit.c:149)
>
> This problem is clearly that the easy handle has been killed off
before the
> connection, and for some reason is the easy handle still left in the
recv_pipe
> when the connection is disconnected and then it assigns the struct
member
> when 'data' points to already-freed memory...

Exactly.

Ravi.
Received on 2006-09-18