On Mon, 18 Sep 2006, Ravi Pratap wrote:

> Oops, you're right. easy_conn is already NULL at that point.

Yes, at least it is that at times.

> I need to talk to Daniel about the right way to fix this. The easy handle
> really shouldn't be in the recv_pipe of the connection in the first place.

The disconnect that seems to cause the major problem is the
ConnectionKillOne() function that gets called if the connection cache is full
when ConnectionStore() wants to store a new connection. If I run Michael's
test program without that condition never getting true (i.e all new
connections fit in the cache) I don't get any crach or even valgrind report
(apart from a very annoying false positive I get on getaddrinfo() all the
time).

But this said, avoiding that disconnect only hides the problem since we can
still see that some receive pipes still seem to have pointers left to easy
handles when they are about to get killed. I'm working on figuring out how
this can be. I'm considering clearing up the situation with connections and
easy handles to make it more controlled when they refer to each other and
they should stop doing that.

Anyway, using the attached patch you can detect a few of these run-time
problems, but you also need to make sure the test code (debugit.c) doesn't
call curl_multi_remove_handle() but only does curl_easy_cleanup() directly on
the easy handle. The patch is only meant to be used for tracking down these
problems.

This patch outputs "MAJOR problem..." when it finds a connection with a
pointer to the handle about to get closed (remember to modify the test app).

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html