Lots of work and analysis by "xbx___" in bug #1431750

(http://curl.haxx.se/bug/view.cgi?id=1431750) helped me identify and fix two
different but related bugs:

1) Removing an easy handle from a multi handle before the transfer is done
   could leave a connection in the connection cache for that handle that is
   in a state that isn't suitable for re-use. A subsequent re-use could then
   read from a NULL pointer and segfault.

2) When an easy handle was removed from the multi handle, there could be an
   outstanding c-ares DNS name resolve request. When the response arrived,
   it caused havoc since the connection struct it "belonged" to could've
   been freed already.

Now Curl_done() is called when an easy handle is removed from a multi handle
pre-maturely (that is, before the transfer was complteted). Curl_done() also
makes sure to cancel all (if any) outstanding c-ares requests.

1 files changed, 5 insertions, 1 deletions

diff --git a/lib/url.c b/lib/url.c
index 0c0933ca8..60172b395 100644
--- a/lib/url.c
+++ b/lib/url.c
@@ -3654,7 +3654,7 @@ static CURLcode CreateConnection(struct SessionHandle *data,
   /* Continue connectdata initialization here.
    *
    * Inherit the proper values from the urldata struct AFTER we have arranged
-   * the persistent conncetion stuff */
+   * the persistent connection stuff */
   conn->fread = data->set.fread;
   conn->fread_in = data->set.in;
 
@@ -3999,6 +3999,10 @@ CURLcode Curl_done(struct connectdata **connp,
 
   Curl_pgrsDone(conn); /* done with the operation */
 
+  /* for ares-using, make sure all possible outstanding requests are properly
+     cancelled before we proceed */
+  ares_cancel(data->state.areschannel);
+
   /* if data->set.reuse_forbid is TRUE, it means the libcurl client has
      forced us to close this no matter what we think.