On Mon, 16 Oct 2006, Jeff Pohlmeyer wrote:

>> Please try the attached patch and see if it doesn't make things better!
>
> Yes, that seems to solve the DNS timeout problem completely,

Great, I committed it now. One more down at least.

> but I am still getting handles that are stuck in the PERFORM state, with no
> libevent timer pending, even when I set LOW_SPEED_LIMIT=1 and
> LOW_SPEED_TIME=30.

This is also not very strange, since there's no expire timer for the LOW_SPEED
situation! I committed a fix now that really should set a timer no more than
30 seconds away for that set of options...

> With those settings, it would seem like *something* should happen at least
> every 30 seconds or so, either I receive some more data, or I should get a
> "Operation too slow" error on one of the handles, but it just isn't
> happening.

I think the problem without those settings set are more strange, since when in
perform and the sockets are in "RECVING" state as shown in your dump, and your
app is waiting for them to receive, then there's not much libcurl can do to
screw up. There simply is a set of sockets that it keeps track of that are
waiting to receive data...

> This is what the last debug dump looks like, even after being stuck for
> around five minutes. Maybe you can spot something here that I can't see.

> app: easy= 0x809029c, evset=YES pending=[READ] socket 12 [RECVING]
> lib: easy 0x809029c, state PERFORM, 1 sockets 12 [RECVING]
>
> app: easy= 0x80d1cec, evset=YES pending=[READ] socket 17 [RECVING]
> lib: easy 0x80d1cec, state PERFORM, 1 sockets 17 [RECVING]

Here's an idea for some further debugging: When this situation occurs, you
could write up something that forces a curl_multi_socket() on one or more of
the remaining sockets, to see if that makes any difference. I mean, it waiting
for RECVING means that it hasn't received anything so calling
curl_multi_socket() shouldn't make a difference but if it does, it would prove
that there's some case(s) where we can miss such events.

On the other hand, you already said that calling curl_multi_socket_all() has
that effect, so it kind of already has proved this point.

Hm. It would indicate that the network layer already got the data, and
presumably libevent doesn't bug in this aspect so it would mean that it got
the info and then it would have called its callback... And if the callback was
called when data became available, I can't see it it could fail! Grrr,
somewhere my logic must be flawed but I can't see it right now...

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html