Folks,
I'm trying to debug a libcurl problem on a remote machine. The box is
running 7.20.0. It was in the process of being upgraded to the latest
build, which contains 7.20.1. The update software is built on PyCurl.

I'm not able to reproduce this problem with a test case yet, but I was
hoping that someone here might have some suggestion about how to
proceed. From using DTrace, it looks like the library has two active
handles. Calls to curl_multi_perform return a running_handles count of
2. When I grab the Curl_one_easy out of the call to multi_runsingle(),
it appears that the remaining handles are stuck in CURLM_STATE_WAITDO
and CURLM_STATE_INIT, although the init state may be bogus. The easy
handles are configured to have a connect timeout and a low speed
timeout, but neither of these has triggered to boot the handle out of
being stuck in this state. Can anyone postulate a situation where
writechannel_inuse should be False, but was somehow left as True?

On a related note, is there any other defensive programming I could have
done to avoid this scenario? It doesn't look like any of the timeouts
are checked in this state. Should handles remain in this multi state
indefinitely?

Thanks,

-j
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2010-06-10