On Sun, 26 Oct 2008, Josef Drexler wrote:

> rtorrent uses the multi socket interface, and normally it all works fine.
> However some users of libcurl 7.18.2 and 7.19.0 have reported that
> occasionally some transfers stall permanently, despite CURLOPT_TIMEOUT being
> set to 120 seconds. That is, despite calling curl_multi_socket_action
> regularly, the amount of running handles that it returns doesn't change when
> the timeout passes and the app never receives a notification for this
> transfer from curl_multi_info_read.

It _could_ be the same timer error I've tried to fix in CVS like this:

    http://cool.haxx.se/cvs.cgi/curl/lib/multi.c.diff?r1=1.183&r2=1.184

There are some sympthoms discussed in the bug report:

    http://curl.haxx.se/bug/view.cgi?id=2111613

> Because I haven't been able to reproduce the crash myself, I need some hints
> on how best to investigate this crash. Is it possible that libcurl has
> internally removed the easy handle without adjusting the number of running
> transfers

If it can do it or does it, it is a bug.

> Is there a way of testing whether an easy handle is still supposed to be
> valid (that doesn't crash libcurl in the process)

Well, if you build libcurl with --enable-debug it will trash the memory
before it does free() so you'll quickly see if you use already freed memory.
Otherwise an invalid handle is most probably pointing to freed memory so it's
not really safe for anyone to read it and check it for validity.

There is a 'magic' field at the end of the 'struct SessionHandle' that
contains CURLEASY_MAGIC_NUMBER for all valid handles that can be checked for
as long as the data isn't freed...

In general I guess valgrind (or similar) is the way to check for this, but it
does slow down things and it might be hard to get users to do it.

> and whether it's still part of a multi handle?

There's a 'multi' field in the 'struct SessionHandle' that points to the multi
handle struct that particular easy handle belongs to (or NULL if none).

> The transfer stall is not in itself a big problem (because it could in
> principle be worked around by manually removing the transfer after a while),
> but if that crashes libcurl it indicates a deeper problem that needs to be
> fixed.

Indeed!

> Basically, even some assert() tests for whether the handles are valid would
> be useful to find out where and why the problem first surfaces.

We're using assert()s too little in the code really. We could benefit from
adding a bunch of them all over to easier track down things like this with
debug-builds...

-- 
  / daniel.haxx.se