Hi! On Sat, 2019-05-04 at 13:02:13 +0100, Alessandro Ghedini wrote: > On Sat, Apr 20, 2019 at 01:39:36PM +0200, Guillem Jover wrote: > > Source: curl > > Source-Version: 7.64.0-2 > > Severity: serious > > Control: affects -1 rtorrent
> > I've started noticing rtorrent busy-looping at some points after > > finishing a torrent. stracing and gdb'ing the process it was doing > > that in its main loop, spamming on gettimeofday() and epoll_wait(). > > > > Checking the rtorrent dependencies I've not seen much suspicious > > updated recently, except for curl. I checked then the upstream bug > > trackers and noticed quite many instances of "100% cpu usage" reports, > > such as <https://github.com/rakshasa/rtorrent/issues/580>. And that > > one points to old and new curl issue. The last instance of it appears > > to have been fixed with <https://github.com/curl/curl/commit/4015fae> > > in 7.64.1. > > > > So I think curl should be either upgraded to that release, or the > > relevant commits cherry-picked. > > I prepared an update for the curl package with the two upstream patches > applied > (38d8e1b and 4015fae), and uploaded the result for amd64 at: > https://people.debian.org/~ghedo/libcurl4_7.64.0-3_amd64.deb > > Guillem, could you try this version of the package and see if it fixes the > issue for you? Once that's confirmed I'll upload to sid and ask for unblock. Thanks! I tried yesterday and today to get a deterministic reproducer with the version from unstable, but I'm not sure what's the trigger, perhaps the torrent peers or the chunk arrival order or something. In any case I was able to get the problem while redownloading some torrents I had around. Installed the new package, and redownloaded several old torrents and several new ones, and none have shown the problem since. But even though I was getting that pretty often before, that does not mean I might have been lucky until now! So, while it does look like the issue is gone, I cannot say that with 100% assurance. :) Will keep checking and report again in a day or two. Thanks, Guillem
