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.
This commit is contained in:
Daniel Stenberg 2006-02-23 12:20:48 +00:00
parent d29147565c
commit 6fdbb01194
5 changed files with 32 additions and 4 deletions

View file

@ -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;