Hey all,

More of me complaining about c-ares! :)
I am experiencing a situation that is as follows:

- using the cURL multi API
- using c-ares for asynchronous resolves
- network is freshly disconnected (i.e. we still have a valid IP address,
route, and DNS server, but the physical link is gone)

We have a Glib-style event loop implementation into which the multi API is
hooked. Presumably due to the network disconnection, polling on the FD
responsible for name resolution is in a 'POLLERR' state (indicating some
error with the socket.) We call curl_multi_socket_action to indicate this
error to libcurl. However, libcurl does not appear to ask us to remove the
FD from the poll loop. Our event loop keeps spamming the POLLERR state, and
we keep looping like this:

(Note: c-ares is statically linked into libcurl.so.4)

#0 0xb4fee2d6 in ares_waitperform () from libcurl.so.4
#1 0xb4fee5a4 in Curl_is_resolved () from libcurl.so.4
#2 0xb4fe9edb in multi_runsingle () from libcurl.so.4
#3 0xb4fea82d in multi_socket () from libcurl.so.4
#4 0xb4fea901 in curl_multi_socket_action () from libcurl.so.4
#5 0xb63e7d3b in TransferData (httpH=0x91dee68, fd=147) at http.c:913

ares_waitperform returns immediately and keeps getting called because of the
POLLERR state, so our UI becomes totally blocked.

Why isn't c-ares causing the DNS socket to expire because of the POLLERR
state?

A casual peek at the source code shows that ares_waitperform (hostares.c)
does not check for a POLLERR state. Could that be the problem?

-Josh
Received on 2009-07-29