qBittorrent
qBittorrent copied to clipboard
qbittorrent
v4.6.x memory leak
qBittorrent & operating system versions
qBittorrent: 4.6.2 Operating system: ArchLinux Qt: 6.6.1 Libtorrent-rasterbar: 2.0.9.0
What is the problem?
qbittorrent 4.6.x eat up the whole memory. Least in a few hours, most to 1 day, the program will start a random time, to occupy a cpu core, increase RSS memory usage at about 3 MiB/s, as well as 1~2 MiB/s disk write. qbittorrent start up at a normal mem usage of about 500 MiB, the leak process will continue until it rises to 6 GiB, and next time 11.2 GiB, then my 16 GiB machine will stuck due to low memory ( sometimes luckily the oom-killer bring my machine back to work ). Didn't notice the issue in 4.5.x, but at that time i was using memory-mapped file option in libtorrent so i can't tell the issue is not with 4.5.x. BTW I first noticed the issue when using qbittorrent-enchanced, but same issue can be reproduced in Arch offical package qbittorrent
Steps to reproduce
- Start qbittorrent 4.6.x.
- Wait till the memory start to leak. Seeding or not don't change the memory usage.
Additional context
I tried to trace the issue with gcore and pmap. The following block is the output of gdb info proc mappings
Mapped address spaces:
Start Addr End Addr Size Offset objfile
0x5577ae2c7000 0x5577ae426000 0x15f000 0x0 /usr/bin/qbittorrent
0x5577ae426000 0x5577ae885000 0x45f000 0x15f000 /usr/bin/qbittorrent
0x5577ae885000 0x5577aefa7000 0x722000 0x5be000 /usr/bin/qbittorrent
0x5577aefa7000 0x5577aefc6000 0x1f000 0xce0000 /usr/bin/qbittorrent
0x5577aefc6000 0x5577aefcd000 0x7000 0xcff000 /usr/bin/qbittorrent
0x7fbd0ec00000 0x7fbd0f61a000 0xa1a000 0x0 /usr/share/fonts/noto/NotoColorEmoji.ttf
And pmap shows the memory address between 0x5577aefcd000 and 0x7fbd0ec00000 was [heap]
Log(s) & preferences file(s)
Switch to using qBittorrent with libtorrent 1.2.19
Dupe of https://github.com/qbittorrent/qBittorrent/issues/19914
Switched and recompiled with libtorrent 1.2.19, the issue still occurs. I don't think the issue duplicate with #19914.
I'm facing similar issue on NAS(QNAP) system, @Zylsjsp how can I make sure we are the same problem?
Something similar happened when I switched server. I let old server I was canceling just seed 140ish torrents with qbittorrent 4.6.0/.1 without downloading anything, and the memory kept growing until it started swapping like crazy. I didn't open a bug report as I switched from rtorrent to qbittorrent last month or so, and I was/am still not sure about all the settings for qbitorrent/libtorrent 1.2.9.
When it happened, I stopped all the torrents and i did a cat /proc/$(pidof qbittorrent-nox)/smaps. And when I dumped the memory with gdb at the addresses that had with 63556KB in the "Swap/referenced/Anonymous" of smaps, all I could see was unreadable/encrypted-like data garbage with the occasional filename of a file that was seeding before I stop all the torrents.
It didn't happen when the server was actively downloading and seeding, and it doesn't happen on my new server that's downloading and seeding. The memory grows and get freed when the client downloads a torrent.
Having the similar issue on Raspberry Pi4 8GB. 4.6.2 + Docker + Raspbian Bookworm 64bit. Slowly fills the whole RAM, then Raspberry just freezes and I can't access SSH or any other service, need to reset the power.
Having the similar issue on Raspberry Pi4 8GB. 4.6.2 + Docker + Raspbian Bookworm 64bit.
Are you also using libtorrent 2.0.9 in your 4.6.2 build? Have you tried a 4.6.2 build with libtorrent 1.2.19 instead?
Having the similar issue on Raspberry Pi4 8GB. 4.6.2 + Docker + Raspbian Bookworm 64bit.
Are you also using libtorrent 2.0.9 in your 4.6.2 build? Have you tried a 4.6.2 build with libtorrent 1.2.19 instead?
Yes, it is 2.0.9. Is any other docker image with 1.2.19? I use this one
Yes, it is 2.0.9. Is any other docker image with 1.2.19? I use this one
According to that page you should install the one with the libtorrentv1 tag to get an image with 1.2.19
Yes, it is 2.0.9. Is any other docker image with 1.2.19? I use this one
According to that page you should install the one with the libtorrentv1 tag to get an image with 1.2.19
Thanks, looks like with 1.2.19 it works as expected, the memory usage is stable and don't rise above 512 MB limit set in the settings.
Weird...My build with 1.2.19 doesn't have a memory limit option in the qbittorrent section and the memory usage still blows up with libtorrent1. Or I need to reset configuration when switching between 2.x and 1.2.19?
Stepyon @.***> 于2023年12月23日周六 20:34写道：
Yes, it is 2.0.9. Is any other docker image with 1.2.19? I use this one https://hub.docker.com/r/linuxserver/qbittorrent
According to that page you should install the one with the libtorrentv1 tag to get an image with 1.2.19
Thanks, looks like with 1.2.19 it works as expected, the memory usage is stable and don't rise above 512 MB limit set in the settings.
— Reply to this email directly, view it on GitHub https://github.com/qbittorrent/qBittorrent/issues/20117#issuecomment-1868285478, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMSCBN7LFEHFP2IGZKPEINTYK3FUDAVCNFSM6AAAAABAOS52F6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRYGI4DKNBXHA . You are receiving this because you were mentioned.Message ID: @.***>
Or I need to reset configuration when switching between 2.x and 1.2.19?
I personally don't touch the configuration at all. Never see that issue with 1.2.19.
I'm encountering this issue as well. Using binhex docker container on unraid. I have 32GB RAM. Using the "free -m" I noticed my available RAM going down from 18GB to 9GB in a about half an hour. And during that time, the qBit RAM has increased to 21GB as seen in htop. Now I know about https://www.linuxatemyram.com/ but the fact that the available RAM is going down so fast is alarming.
I've left the Physical RAM limit under Options -> Advanced to 512MiB, as it was when I installed the docker container.
My unraid server has froze up multiple times in the last few days due to this and I could only hard reset it, just like @Stepyon with his raspberry pi.
Is this issue being worked on? Is it known that the Physical RAM limit setting in qBit is basically being ignored in some cases? Should I downgrade to a 4.5.x docker container in the meantime or what's the advice?
I'm facing this too, was about to make an issue, here's a visual look at Memory Usage when exiting qBittorrent. Note that while I didn't show in this, the Memory usage listed under qBittorrent in Task Manager is only 3GB~ yet clearly its using like 20GB.
qBittorrent: 4.6.0 (64-bit)
Qt: 6.4.3
Libtorrent: 1.2.19.0
Boost: 1.83.0
OpenSSL: 1.1.1w
zlib: 1.3
Processor: Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz
RAM: 48.0 GB
System type: 64-bit operating system, x64-based processor
https://github.com/qbittorrent/qBittorrent/assets/17136956/37125bdd-5c01-466c-8ad7-29a4c043cef4
i have a simple assumption that the issue comes with complex network interfaces and corrupted connection. for me the issue seem to occur only when i'm using clash (a proxy server with TUN feature). with the fake-ip mode defined in RFC3089, another issue in clash is that the very first time a connection establishes with failure, then the fakeip become available for connection. the issue is not serious when using a web browser, but it seems that the libtorrent dns module is less flexible than a common browser. it often keep old connections or outdated dns cache, and the failing connections might be to blame for an huge consumption of memory.
unsure discovery: memory leak seems to be related to rss feed module. did anyone notice the same situation?
memory leak seems to be related to rss feed module.
Any details? Reliable/confirmed steps to reproduce?
I'm encountering this issue as well. Using binhex docker container on unraid. I have 32GB RAM. Using the "free -m" I noticed my available RAM going down from 18GB to 9GB in a about half an hour. And during that time, the qBit RAM has increased to 21GB as seen in htop. Now I know about https://www.linuxatemyram.com/ but the fact that the available RAM is going down so fast is alarming.
I've left the Physical RAM limit under Options -> Advanced to 512MiB, as it was when I installed the docker container.
My unraid server has froze up multiple times in the last few days due to this and I could only hard reset it, just like @Stepyon with his raspberry pi.
Is this issue being worked on? Is it known that the Physical RAM limit setting in qBit is basically being ignored in some cases? Should I downgrade to a 4.5.x docker container in the meantime or what's the advice?
In the end, for me it turned out to be a memory leak caused by having two instances of the binhex-qbittorrentvpn docker container open in the same browser and using the same hostnames. See more information here: https://forums.unraid.net/topic/75539-support-binhex-qbittorrentvpn/page/131/#comment-1388623
Now it would be great to know if this is a memory leak caused by the qbittorrent program, or by the binhex docker implementation. But I'm guessing the former. Would be great if someone could verify this to be the case.
memory leak seems to be related to rss feed module.
Any details? Reliable/confirmed steps to reproduce?
Confirmed. One of my rss feed from pt site renders articles ugly and caused the issue.
For example, the following article renders well and won't cause memory leak.
On the contrary, the following article renders bad and caused the issue.
(Through htop can see a high single-core cpu usage, and a low rate io write at a rate less than 10 MiB/s on my machine)
Simply click on other normal articles will terminate the render process, also stop leaking.
Additional information is that the second rss from pt usually contain relative path in url, so rss reader will never get the genuine resource. In my view either an adaptation to relative path in url or simply abort loading will be a fix.
Additional information is that the second rss from pt usually contain relative path in url, so rss reader will never get the genuine resource. In my view either an adaptation to relative path in url or simply abort loading will be a fix.
Could you at least share such RSS feed URL so that someone can test/debug it? Or if it's some kind of private feed, so that someone can't access it (without unnecessary worries), could you provide a snapshot of its content (XML data received from feed URL)?
Could you at least share such RSS feed URL so that someone can test/debug it? Or if it's some kind of private feed, so that someone can't access it (without unnecessary worries), could you provide a snapshot of its content (XML data received from feed URL)?
Sure. The normal public rss link is https://bangumi.moe/rss/latest. The snap of the private feed is snap.xml.txt (passkey removed)
I'm having the same issue, crashing on v4.5.4, just as https://github.com/qbittorrent/qBittorrent/issues/20117#issuecomment-2043470240 I had two instances of qBitttorents running, and the problem went away when I stop one instance.
It would be good to know what is causing the issue or how to avoid it.
I'm having the same issue, crashing on v4.5.4, just as #20117 (comment) I had two instances of qBitttorents running, and the problem went away when I stop one instance.
It would be good to know what is causing the issue or how to avoid it.
if your problem is the same rss issue like me, just ensure the pages with problem are not focused on anytime you leave the rss reader.
I'm having the same issue, crashing on v4.5.4, just as #20117 (comment) I had two instances of qBitttorents running, and the problem went away when I stop one instance.
It would be good to know what is causing the issue or how to avoid it.
It indeed had to do with running 2 instances of the container for me. But it can be done, you just have to make sure you don't run 2 webUI's using the same hostname in the same browser. That's where the memory leak exists. Read more about it here: https://forums.unraid.net/topic/75539-support-binhex-qbittorrentvpn/?do=findComment&comment=1388623
It indeed had to do with running 2 instances of the container for me. But it can be done, you just have to make sure you don't run 2 webUI's using the same hostname in the same browser. That's where the memory leak exists. Read more about it here: https://forums.unraid.net/topic/75539-support-binhex-qbittorrentvpn/?do=findComment&comment=1388623
Yeah, I was using same hostname within the same browser. I will try it with different browser next time.
I have a too problem on version 4.6.5 from 2024-07-29
OS gentoo net-p2p/qbittorrent-4.6.5::gentoo USE="webui -dbus -gui -qt6 -systemd -test -verify-sig"
Rebooted my server about 30 minutes ago
Same issue here with 4.5.x and 4.6.x In my case, not related to the rss feeds because I don't have them enabled and usually only happens when the amount of uploaded data of a big torrent (>20 GB) is high. If I remove those big torrents or no data is uploaded from them, there is no high memory usage.
@Uukrull then your issue seems to be related with mmap options, I guess. #16146
I'm having the same issue, crashing on v4.5.4, just as #20117 (comment) I had two instances of qBitttorents running, and the problem went away when I stop one instance. It would be good to know what is causing the issue or how to avoid it.
It indeed had to do with running 2 instances of the container for me. But it can be done, you just have to make sure you don't run 2 webUI's using the same hostname in the same browser. That's where the memory leak exists. Read more about it here: https://forums.unraid.net/topic/75539-support-binhex-qbittorrentvpn/?do=findComment&comment=1388623
Same problem for me. I'm running qbittorrent v5.0.4 and v4.6.7 (https://github.com/linuxserver/docker-qbittorrent), and when opening the webUIs on the same browser I get a memory leak that causes the server to go irresponsive.
I recorded a video showing this behavior
https://github.com/user-attachments/assets/c83f351c-70f5-4f95-b627-51511b64d016
Until 0:13 I was with the 2 webUIs opened.
Same problem for me. I'm running qbittorrent v5.0.4 and v4.6.7 (https://github.com/linuxserver/docker-qbittorrent), and when opening the webUIs on the same browser I get a memory leak that causes the server to go irresponsive.
I recorded a video showing this behavior
As you can see on the unraid forums, you can still use two instances in the same browser, as long as you navigate to the first one as http://192.168.1.1:8080 and then second one as http://tower.local:8081.