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
