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, 4 insertions, 2 deletions

diff --git a/lib/multi.c b/lib/multi.c
index a7d1988d6..6213fede4 100644
--- a/lib/multi.c
+++ b/lib/multi.c
@@ -92,10 +92,10 @@ struct Curl_one_easy {
   int msg_num; /* number of messages left in 'msg' to return */
 };
 
-
 #define CURL_MULTI_HANDLE 0x000bab1e
 
-#define GOOD_MULTI_HANDLE(x) ((x)&&(((struct Curl_multi *)x)->type == CURL_MULTI_HANDLE))
+#define GOOD_MULTI_HANDLE(x) \
+  ((x)&&(((struct Curl_multi *)x)->type == CURL_MULTI_HANDLE))
 #define GOOD_EASY_HANDLE(x) (x)
 
 /* This is the struct known as CURLM on the outside */
@@ -245,6 +245,8 @@ CURLMcode curl_multi_remove_handle(CURLM *multi_handle,
     Curl_easy_addmulti(easy->easy_handle, NULL); /* clear the association
                                                     to this multi handle */
 
+    Curl_done(&easy->easy_conn, easy->result);
+
     /* make the previous node point to our next */
     if(easy->prev)
       easy->prev->next = easy->next;