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
