On Fri, 3 Jun 2016, supercaowei wrote:

> I sent an https request and the server answered me with a redirected url. So
> the redirected url request would be automatically sent. But, before it was
> sent ( function "Curl_http" was not executed, and the session handle's
> mstate was CURLM_STATE_WAITRESOLVE ) , the execution entered the function
> "singlesocket" in file multi.c. Then, CURL_POLL_REMOVE was called to the
> sockect callabck set by me. So, the socket was removed. In result, the whole
> session handle was removed too and the corresponding connection is closed.
> That means, the redirected url request was never sent.

You leave out some vital information here that makes this hard to follow.

I assume you had CURLOPT_FOLLOWLOCATION set so that it would actually follow
the direct?

If so, was the second URL that it would redirect to on a different host name?
It sounds like that, and if that is true then isn't it expected that your
application should stop caring about the first connection (CURL_POLL_REMOVE)
and then start caring about the new one once it gets created and told about to
the application?

> I traced into the function "singlesocket" in file multi.c, it was executed like below :
> static void singlesocket(struct Curl_multi *multi, struct SessionHandle *data)

...

> Later, in the socket_cb, I checked how many active sockets the session
> handle still has. When I find it's 0, I destroyed the session handle.

There's your problem. Don't do that. libcurl tells you when the transfer is
completed, and before it has told you the transfer isn't completed and you are
probably better off not trying to second-guess it.

A transfer can very well have no active file descriptors/sockets to monitor
and still be alive. Like when doing a name resolve with the threaded resolver.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:  https://curl.haxx.se/mail/etiquette.html