Hi,

Occasionally, curl_multi_perform "returns"
CURLE_COULDNT_RESOLVE_HOST without reason for an "easy
handle". curl_easy_cleanup can also crash afterwards.
I think the problem is due to a race condition in the
resolving code.

In hostthre.c -> Curl_is_resolved, the following check
is done:
-----------------------------
if (conn->async.done) {
    /* we're done */
    destroy_thread_data(&conn->async);
    if (!conn->async.dns) {
      return CURLE_COULDNT_RESOLVE_HOST;
    }
-----------------------------

In hostasyn.c -> addrinfo_callback however, async is
filled in in the following order:
-----------------------------
conn->async.done = TRUE;
conn->async.status = status;
...
conn->async.dns = dns;
-----------------------------

Is it possible that the following happens?
1. Resolver thread -> [conn->async.done = TRUE;]
2. curl_multi_perform thread ->
   - conn->async.done is now TRUE
   - conn->async.dns is NULL
   - so we return CURLE_COULDNT_RESOLVE_HOST
   [if (conn->async.done) {
    /* we're done */
    destroy_thread_data(&conn->async);
    if (!conn->async.dns) {
      return CURLE_COULDNT_RESOLVE_HOST;
    }]
3. Resolver thread -> [conn->async.dns = dns;]
4 ...

I think
conn->async.done = TRUE;
should be at the bottom of addrinfo_callback to fix
the wrong CURLE_COULDNT_RESOLVE_HOST result. The crash
I mentioned is probably related (we call
curl_easy_cleanup because we think libcurl has
finished with it but the thread is still running).

Best regards,
Chris

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Received on 2004-09-28