Short story long there's an issue with >=libtorrent-rasterbar-2.0, that has been widely reported [1]. After a long debate and some heated opinion sharing, qbittorrent upstream was convinced to switch back to libtorrent-1.2 in their official builds for all platforms, while still providing 2.0 as an option [2]. The issue in libtorrent is convoluted and difficult to diagnose, similar to the famous 12309 linux kernel "bug", and it is complicated even further by misreporting of the amount of RAM used by an app in linux, which lead to a couple of linuxatemyram.com references. But I am affected by the real issue, when adding a large torrent in qbittorrent (around 10GB), the whole system locks up hard for about 10 minutes. So hard, that I can't even run `ps`, I'm guessing because the system can't read the binary from the disk to start it. And after 10 minutes of HDD activity LED being solid on, it goes back to normal, and everything works fine. So, what I propose is depending on <libtorrent-rasterbar-2.0 by default. Ideally while still providing an option to switch to >=2.0 for not affected users. Basically following what the upstream did. On one hand, it's easy enough for me to mask >=net-libs/libtorrent-rasterbar-2.0 and Gentoo wouldn't have to do anything, but on the other hand, I just didn't know it's that easy to solve, and I have been affected for months. So I think it's safer default for a new user that knows nothing of specifics. [1] https://github.com/arvidn/libtorrent/issues/6667 [2] https://www.qbittorrent.org/news.php Reproducible: Always
*** Bug 839567 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=68140f7e4f3bf8a13628bf06a093bdf51df4ac28 commit 68140f7e4f3bf8a13628bf06a093bdf51df4ac28 Author: Piotr Karbowski <slashbeast@gentoo.org> AuthorDate: 2022-11-10 08:46:51 +0000 Commit: Piotr Karbowski <slashbeast@gentoo.org> CommitDate: 2022-11-10 08:48:53 +0000 net-libs/libtorrent-rasterbar: 2.0.8 version bump. Closes: https://bugs.gentoo.org/show_bug.cgi?id=880595 Bug: https://bugs.gentoo.org/868480 Signed-off-by: Piotr Karbowski <slashbeast@gentoo.org> net-libs/libtorrent-rasterbar/Manifest | 1 + .../libtorrent-rasterbar-2.0.8.ebuild | 75 ++++++++++++++++++++++ 2 files changed, 76 insertions(+)
The 2.0.8 version should have the fix for it, please check.
Checked not even 3 hours after the upstream release. Negative on the fix. Reported in the upstream issue tracker.
I will see how it goes here. It was quite extensively deadlocking on me. If I can reproduce it, I will bump the ebuild to force pre-2.0 release. As a quick fix, I think you are better with package.mask'ing the >-2.0.
I've done that. However, if qbittorrent ebuild forces <2.0, without giving an IUSE to go to >=2.0, the next time I will have to put it in ::local to test the next libtorrent-rasterbar release, and I wouldn't have checked it that easily, so please keep that in mind.
I do not think pushing IUSE for the solo purpose of simple testing in future with new lib is worth it. I have git based ::gentoo, so I'd just edit ebuild, test it and then 'git reset --hard' to get rid of my local changes. I can recommend similar workflow for you.
I see your point, I wouldn't insist.
@Michael so far it seems to be stable here so far, I had qbittorrent ran for its money and it did not crashed, or gave me random I/O errors like it used to on 2.0.7 libtorrent. Are you sure you updated lib and rebuilt qbittorrent with new headers rather than just install new libtorrent?
(In reply to Piotr Karbowski from comment #9) > Are you sure you updated lib and rebuilt qbittorrent > with new headers rather than just install new libtorrent? Of course. Portage rebuilds it for you nowadays, it's kinda difficult to mess up. But 12309 was on my mind for a reason. The issue people are complaining about is probably a bunch of different issues, manifesting in similar ways. Besides, Arvidn promised "mitigations", which I assume means he did something he think might help in some conditions. I don't think he meant he identified and fixed the issue, in which case I think he'd say "fix", not "mitigations".
I see that more people confirms they are still affected on 2.0.8 but also Deluge client hits this hard. I will later today push bump to ebuild to force the 1.x series libtorrent.
Like I mentioned, there's a lengthy and pretty nutty discussion in the upstream report. If you ever have half an hour of nothing better to do, you can skim through it, it might give you a couple of giggles. But of course, anything using libtorrent, deluge included, would be affected.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5eda440ff49707a83a509dc92f0c6c84c0ba5269 commit 5eda440ff49707a83a509dc92f0c6c84c0ba5269 Author: Piotr Karbowski <slashbeast@gentoo.org> AuthorDate: 2022-11-19 15:28:05 +0000 Commit: Piotr Karbowski <slashbeast@gentoo.org> CommitDate: 2022-11-19 15:29:38 +0000 net-p2p/qbittorrent: 4.4.5-r1, <net-libs/libtorrent-rasterbar-2. Closes: https://bugs.gentoo.org/868480 Signed-off-by: Piotr Karbowski <slashbeast@gentoo.org> net-p2p/qbittorrent/qbittorrent-4.4.5-r1.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Missing revbump?
Good catch, I was sure r1 was what I bumped. Will pay more attention to it.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b5f1aa197207810a229fd6b13b136a752a673fd6 commit b5f1aa197207810a229fd6b13b136a752a673fd6 Author: Piotr Karbowski <slashbeast@gentoo.org> AuthorDate: 2022-11-19 17:10:16 +0000 Commit: Piotr Karbowski <slashbeast@gentoo.org> CommitDate: 2022-11-19 17:10:50 +0000 net-p2p/qbittorrent: 4.4.5-r2 revbump. Bug: https://bugs.gentoo.org/868480 Signed-off-by: Piotr Karbowski <slashbeast@gentoo.org> .../{qbittorrent-4.4.5-r1.ebuild => qbittorrent-4.4.5-r2.ebuild} | 0 1 file changed, 0 insertions(+), 0 deletions(-)
I confirm both net-libs/libtorrent-rasterbar-2.0.8 and net-libs/libtorrent-rasterbar-2.0.9 are filling my RAM, more than 20 gb out of 32 gb of RAM are used and my system becomes unresponsive.
