Memory leak leading to completely frozen system.

[bacon-cheeseburger]

qBittorrent & operating system versions

qBittorrent-nox: compiled from git master (5.0.0beta1-r12813-git+b52fa98a0)
OS: debian linux (sid)
Qt: 6.6.2
libtorrent-rasterbar: compiled from git master (1.2.19-r12321-git+231613643)

What is the problem?

It appears there's a memory that eventually leads to a completely frozen system that requires a power cycling to recover from. No core file is dumped (due to no memory I assume). The system has 16GB ram and within 48 hours (I think), qbittorrent-nox will have eaten all the ram. In my case I didn't add any new torrents. It was only seeding.

Steps to reproduce

1. Compile git master.
2. Start it and let it sit until it crashes.

Additional context

I was previously running git master r12552.git+7bd8f262d because Debian was floundering on Qt6.4 until they recently, finally, updated (to 6.6). That version was solid, no memory leak problem. I haven't done a bisect and hopefully won't have to because of the range I'd need to compile & test. I'm not sure what other info is helpful. Fingers crossed this is a known issue already.

Log(s) & preferences file(s)

No response

[HanabishiRecca]

Probably related to #20675, #20873

[bacon-cheeseburger]

@HanabishiRecca I read through the linked reports and the problem I'm experiencing does seem to be the same or related. Further detail here is, I'm running 3 instances of qbittorrent-nox, each in their own network namespace. So not fully containerized but enough that each one has its own network stack. Each uses a unique subnet and different webui port, which I manage in the default network namespace using nftable filters. I monitor the instances via the webui from Ungoogled Chrome on a Windows system.

I can try bisecting this if necessary.

[luzpaz]

I can try bisecting this if necessary.

@bacon-cheeseburger that would be helpful

[bacon-cheeseburger]

I tried doing this shortly after my last reply here. At that time what I observed was the last good commit being 5.0.0beta1-r12817-git+eba5cbb80. The next commit, 5.0.0beta1-r12816-git+87a202c71, I started seeing much higher memory usage. That being said, the results were a little inconsistent. It might be better to ask someone with much larger downloads/seeds to try bisecting as that may make the results much more obvious (not to mention quicker).

Another option could be to add in some debugging to help isolate where things may be going sideways. Hopefully someone more capable than myself can navigate the path to a fix.

[HanabishiRecca]

Interesting information.

5.0.0beta1-r12816-git+87a202c71

Worth to mention that this commit still did not make it into release.
Is current release build problematic for you?

[bacon-cheeseburger]

Interesting information.

5.0.0beta1-r12816-git+87a202c71

Worth to mention that this commit still did not make it into release. Is current release build problematic for you?

I mistakenly thought the fix has been merged. Unfortunately it hasn't, not sure why. The following PR fixes the problem I reported: #21619