Memory leak

[moonlitpath]

qBittorrent & operating system versions

qBittorrent: 5.0.0 x64
Operating system: Gentoo
Qt: 6.7.2
libtorrent-rasterbar: 2.0.10

What is the problem?

qBittorrent leaks memory on my system when downloading torrents. I first noticed the leak on 4.6.6 and decided to upgrade and see if the issue is fixed in the up-to-date version. qBittorrent started with ~200 MiB of RAM but at the time of writing this it has consumed 3.5 GiB. When I pause torrents, all the leaked memory is released.

Steps to reproduce

1. Start downloading any torrent, preferably a huge one (20 GiB or more)
2. Observe qBittorent consuming more and more memory over time

Additional context

No response

Log(s) & preferences file(s)

https://gist.github.com/moonlitpath/41c7a72752ca980d02c3a6d395cd50f4

[moonlitpath]

Sorry if it's a duplicate. I found several similar reports but IDK if I'm facing the same issue.

[HanabishiRecca]

Does it resemble arvidn/libtorrent#6667?

[moonlitpath]

Yes, it does. Downgrading libtorrent to 1.2.19 fixes memory usage.

[HanabishiRecca]

If you are interested in testing, try this patch #21300. (I think I don't need to explain how to patch&build stuff for a Gentoo user.)
Then you go into advanced settings tab and set Disk IO type to Simple pread/pwrite.

Also there is a libtorrent patch arvidn/libtorrent#6667 (comment), it improves performance a lot for this new mode.

[hekkr000]

I'm not entirely sure, if it's only related to the issue above. I also updated to 5.0.0 yesterday, and noticed several freezes on my systems. I managed to figure out the reason, they run out of memory. Apparently qbittorent starts to use more than 40gb after a while... I reinstalled a previous 4.6.4 package and it works normally again. I was able to replicate this on two of my arch servers. The libtorrent stayed the same (2.0.10). Not sure that it matters but I'm also using the nox version, as I have no desktop manager on these systems. I also use the API quite heavily, with thousands of active torrents. My normal memory usage for qbt is around 5 gb, which has been stable for a while. I also tried disabling the os read write cache in qbt, but that didn't seem to change anything regarding the oom.

[HanabishiRecca]

I reinstalled a previous 4.6.4 package and it works normally again. I was able to replicate this on two of my arch servers. The libtorrent stayed the same (2.0.10).

Looks more like #21502.
In that case, wiping the qBittorrent settings and starting with a clean profile seems to help.

[hekkr000]

I could give it a try, but that would probably take a couple days, rechecking 6k+ torrents with several 10s of TBs of data takes a long time. Do you think it is caused by the fastresume files perhaps? Or you mean only deleting the config files?

[HanabishiRecca]

No, don't wipe the resume data. Only delete the client settings (~/.config/qBittorrent/qBittorrent.conf).
All your tasks will remain intact.

[hekkr000]

I moved to a third server to test, as this one has a bit more free ram. Here qbt was restarting constantly because of the memory issue, which took me some time to realize, as i was only watching it from top... Anyways I was able to update this one as well and get the oom reproduced. Then I deleted the entire ~/.config/qBittorrent directory as you recommended. It got recreated on restart. Set up port, password, default directory and global speed limits only. Still got the same result. Memory usage slowly creeping up on 5.0.0 to around 40gb max, where this system just silently decides to kill it, then systemd restarts it. I'll try to stop the service that does the API calls next, and leave the web ui alone as well. Maybe that's the problem. I also did a negative test on this machine as well, the older version is fine here too, stops around 14gb and stable.

[hekkr000]

It got more interesting over night. I left the server to do it's thing, but apparently with the default config it didn't quite hit the memory limit that it did before, so it didn't got killed, and eventually pushed the memory usage back down to <10gb and is now stable. I put the old config file back, and it didn't seem to mind it with that either now. Is it possible that there is a migration process that needs to complete that uses a lot of memory and if we have our config very lax, with a bunch of connections and active torrents allowed, then it just can't handle it?

[HanabishiRecca]

No. The cause is still unknown.
Libtorrent 2.x is intended to use as much RAM as possible for a cache though. It's easily reproducible if you force re-check on a torrent with few large files (totally larger than your RAM).
So it's unclear what you are seeing.

Try to use libtorrent 1.x build to factor that out. Alternatively, set Disk IO type to POSIX-compliant (don't forget to restart the client) and see if that still reproduces.