WebUI: Memory Leak when multiple WebUIs are open simultaneously

[Jorsher]

qBittorrent & operating system versions

qBittorrent: 4.6.4 x64
Operating system: TrueNAS Scale (Debian Bookworm)
Qt: 6.7.0
libtorrent-rasterbar: 1.2.19

What is the problem?

I run multiple containers/instances of qbittorrent-nox on a server. I do not have hostnames, and access them by http://ip:port. They're all at the same IP with different ports.

If only one client is accessed at a time in the browser, there are no problems. Immediately after opening a second client in the browser, RAM usage by the clients on the host starts climbing rapidly until reaching OOM. If three are open, it occurs on all three. Memory usage in the browser (Firefox) accessing the clients also increases until OOM.

When I close the tabs, the memory is not released on the host. To release the memory, I need to restart the containers.

EDIT: Someone that had different IPs for the clients on the host did not experience the issue.

Steps to reproduce

1. Access the web interface for two clients simultaneously
2. Watch RAM usage by the clients on the host, and the tabs in the browser, increase until OOM

Additional context

No response

Log(s) & preferences file(s)

No response

[Jorsher]

#20675 (comment) seems to see the same issue

[Chocobo1]

@Jorsher
Are you able to reproduce with qbt v5?

[Jorsher]

I'll likely just wait until 5.0 is released. Spent a lot of time building it from source (boost, lt, qt6 as well), wasn't loading my existing torrents.db, and then trying to add a torrent manually was causing a crash. I'm sure that I either built it wrong or used the wrong version of a dependency (latest on all). I don't think the AppImage is an option since I run these headless.

Easy enough to just open one client at a time in the browser. A couple people I've asked with multiple clients:

• one that access them through the same IP but different port encountered the same issue
• one that accesses them through different IPs did not encounter the issue

[dyno10]

I'll likely just wait until 5.0 is released. Spent a lot of time building it from source (boost, lt, qt6 as well), wasn't loading my existing torrents.db, and then trying to add a torrent manually was causing a crash. I'm sure that I either built it wrong or used the wrong version of a dependency (latest on all). I don't think the AppImage is an option since I run these headless.

Easy enough to just open one client at a time in the browser. A couple people I've asked with multiple clients:

• one that access them through the same IP but different port encountered the same issue
• one that accesses them through different IPs did not encounter the issue

I can confirm that accessing WebUI's via different subnets prevents memory leaks. I've updated my most recent post accordingly.

My qbit server has two IP's on separate subnets (192.168.0.xxx and 192.168.100.xxx), so I never got memory leaks when I had only two instances because each qbit instance was using a different subnet. Adding a third instance cause the memory leaks because it was using the same ip as another instance (different ports).

[dyno10]

@Jorsher Are you able to reproduce with qbt v5?

I tested this in qbit v5 and was able to reproduce the issue. I tested it on Ubuntu Server 24.04 with the v5 .appimage posted on the qbit website.

[dyno10]

Per my previous comment, here are two htop screenshots showing memory usage after having two WebUI sessions open simultaneously for over 28hr continuously. These qbit instances each has only a single 600MB torrent seeding (a Debian ISO) and it's not a very active torrent for me. These screenshots were taken roughly 18hr apart.

June 2:

June 3:

[bacon-cheeseburger]

Is there any progress on resolving this within qbittorrent rather than creating additional subnets, or the actual root cause of why running 2 qbt daemons on the same subnet but different ports causes the memory leak?

[Yavd3341]

Hi, I've recently encountered the same issue. In addition to what was already mentioned, WebUIs from different qBittorrent instances seem to interfere between eachother in regard of rid that's being sent with maindata request to API, thus resetting it to 1 every time. But when only one WebUI instance is opened rid increments normally.

maindata?rid=1&m1ufmda0
maindata?rid=1&m1ufmda1
maindata?rid=1&m1ufmda2
maindata?rid=1&m1ufmda3
maindata?rid=1&m1ufmda4
maindata?rid=1&m1ufmda5
maindata?rid=1&m1ufmda6
maindata?rid=1&m1ufmda7
maindata?rid=1&m1ufmda8
maindata?rid=1&m1ufmda9
maindata?rid=1&m1ufmdaa
...and so on

In corresponding responses rid is also set to 1.

Related problem: this unticks tag checkboxes in torrent context menu, allowing to add but not remove tag from torrent (if you're not fast enough).

Software versions:
qBittorrent: 5.0.0 x64 (package: qbittorrent-nox 5.0.0-1)
Operating system: Arch Linux 6.11.1-arch1-1 x64
Qt: 6.7.3 (package: qt6-base 6.7.3-2)
Libtorrent: 2.0.10.0 (package: libtorrent-rasterbar 1:2.0.10-3)
Browser: Firefox 131.0 x64 (same on Windows and Linux)

(Sorry if this brings no value.)

[dezza]

Profiling the code paths for a client running with 1000+ torrents would be the way to go for solving this issue because I honestly don't believe 5.0.0 is better, I accidentally updated to 5.0.0 and WebUI was still 30+ sec to load and still felt unresponsive.

I had to go down to 400-600 torrents before it was responsive again, but I mean.. It still feels sluggish at all times, really..

[dyseg]

I made many tests, and it seems like the problem lays in two things:

• the WebUI session cookie named SID is shared between the two instances, and gets constantly overwritten. This results in 5-10 MB memory increase for ~1000 torrents with every refresh.
• this memory is not freed when the session expires (default is 3600 sec)
• the memory increase stops, when only one instance remains open

qbt.mp4

I created a version, in which the cookie name is appended with the WebUI port number. This way the two instances won't conflict with each other.
Also found that there were some "ApiControllers" which were not deleted, when the session itself was deleted. After those are deleted, the memory consumption is stable for me. You can trigger the same behavior with one instance, if you change the session timeout to 1 sec in the WebUI settings, in which case every 1 second a new session is created, and every expired is deleted.

Feel free to check out the patched version. You can grab an artifact from the finished actions.
https://github.com/dyseg/qBittorrent/tree/webui

I pushed a linux/amd64 docker image based on the official image. You can try it out:
https://hub.docker.com/layers/dyseg/qbittorrent-nox/alpha/images/sha256-163d219f3d9d57380892fb5483a4d9ab865d9e366deac087d3b9db717e61c7d8?context=repo

If it works out I'll send a PR.

Side notes:
I do not use more than one instances. For me the problem occurred, because for some reason, the browser kept a different cookie somehow, which was not overwriteable. So, the following string was sent as cookie to qbittorrent: "SID=4+lLC1Az0C9W5Kgafc0WZAFt6PpR4CCi; SID=TADe5itaGc3BDi/6OJuHOW/y9xdKjgS3"
From which qbittorrent always parsed the first one, detected that this is a non existing session, generated a new SID, sent it back in the response, which overwrote the 2nd SID cookie... And it was going until the docker container memory limit was reached.
Deleting the cookies did not help. For some days, I used private windows for the WebUI to avoid this scenario.

[bacon-cheeseburger]

@dyseg Thank you for your work diagnosing this bug and hopefully arriving at a resolution, finally! I'm testing your fix now and will report back.

For clarity, the patches were applied to 5.1.0alpha1-r12955-git+2d185dc1c git master, built against libtorrent-rasterbar 2.0.11-r13797-git+a3cdc5107 (compiled from RC_2_0 branch).

[bacon-cheeseburger]

Feel free to check out the patched version. You can grab an artifact from the finished actions. https://github.com/dyseg/qBittorrent/tree/webui

...

If it works out I'll send a PR.

I can confirm your fix appears to have resolved this bug. I've been running webuis for 3 separate -nox instances in the same browser for a day straight now and no memory leak! Prior to your fix this would've resulted in 100% memory usage and a total system freeze.

Thank you again for diagnosing and fixing this!

[xavier2k6]

@Piccirello @Chocobo1 @skomerko FYI

[Piccirello]

As noted in #21619 (comment), when accessing multiple qBittorrent instances via the same hostname/IP address, you should give each qBittorrent instance a unique cookie name (#18384). I was not aware of this, but it makes sense: overwriting the cookie will lead to starting a new session, which means doing more work like sending down a full maindata snapshot.

[bacon-cheeseburger]

As noted in #21619 (comment), when accessing multiple qBittorrent instances via the same hostname/IP address, you should give each qBittorrent instance a unique cookie name (#18384). I was not aware of this, but it makes sense: overwriting the cookie will lead to starting a new session, which means doing more work like sending down a full maindata snapshot.

Appending the instance's session cookie name with the instance's webui port creates a unique cookie name, right?

[Piccirello]

Appending the instance's session cookie name with the instance's webui port creates a unique cookie name, right?

Indeed it does.