starred/qBittorrent

Fork 0

mirror of https://github.com/qbittorrent/qBittorrent.git synced 2026-03-02 22:57:32 -05:00

v4.3.5 memory leak #12210

New issue

Closed

opened 2026-02-21 22:27:39 -05:00 by deekerman · 5 comments

deekerman commented

2026-02-21 22:27:39 -05:00

Owner

Originally created by @ghost on GitHub (Jun 14, 2021).

Running v4.3.5 in a docker container using image: linuxserver/qbittorrent:latest

Ever since v4.3.5 there's been a major uptick in memory usage after the WebUI gets launched. The number of torrents has not changed, nor has the configuration, all torrents have been only seeding since launch, no leeching. This is a new behavior in v.4.3.5.

Here's the current configuration.

[AutoRun]
enabled=false
program=

[BitTorrent]
Session\BTProtocol=TCP
Session\Categories=@Variant(\0\0\0\b\0\0\0\0)
Session\CheckingMemUsageSize=128
Session\CoalesceReadWrite=true
Session\DisableAutoTMMByDefault=false
Session\DisableAutoTMMTriggers\CategorySavePathChanged=false
Session\DisableAutoTMMTriggers\DefaultSavePathChanged=false
Session\PieceExtentAffinity=true
Session\SlowTorrentsDownloadRate=1000
Session\SlowTorrentsUploadRate=1
Session\SuggestMode=true
Session\Tags=[REDACTED], [REDACTED], [REDACTED]

[LegalNotice]
Accepted=true

[Network]
Cookies=@Invalid()

[Preferences]
Advanced\IgnoreLimitsLAN=true
Advanced\IncludeOverhead=false
Advanced\RecheckOnCompletion=false
Advanced\trackerPort=9000
Bittorrent\DHT=false
Bittorrent\LSD=false
Bittorrent\MaxUploads=1000
Bittorrent\MaxUploadsPerTorrent=50
Bittorrent\PeX=false
Bittorrent\uTP_rate_limited=false
Connection\GlobalDLLimit=0
Connection\GlobalUPLimit=1024
Connection\PortRangeMin=[REDACTED]
Connection\ResolvePeerCountries=false
Connection\UPnP=false
Connection\alt_speeds_on=false
Downloads\DiskWriteCacheSize=1024
Downloads\PreAllocation=true
Downloads\SavePath=/downloads/complete/
Downloads\SaveResumeDataInterval=5
Downloads\ScanDirsV2=@Variant(\0\0\0\x1c\0\0\0\x1\0\0\0\f\0/\0w\0\x61\0t\0\x63\0h\0\0\0\x2\0\0\0\x1)
Downloads\StartInPause=false
Downloads\TempPath=/downloads/incomplete/
Downloads\TempPathEnabled=true
DynDNS\DomainName=changeme.dyndns.org
DynDNS\Enabled=false
DynDNS\Password=
DynDNS\Service=0
DynDNS\Username=
General\Locale=
MailNotification\email=
MailNotification\enabled=false
MailNotification\password=
MailNotification\req_auth=true
MailNotification\req_ssl=false
MailNotification\sender=qBittorrent_notification@example.com
MailNotification\smtp_server=smtp.changeme.com
MailNotification\username=
Queueing\IgnoreSlowTorrents=true
Queueing\MaxActiveDownloads=10
Queueing\MaxActiveTorrents=99999
Queueing\MaxActiveUploads=99999
Queueing\QueueingEnabled=true
WebUI\Address=*
WebUI\AlternativeUIEnabled=false
WebUI\AuthSubnetWhitelist=192.168.0.0/26, 10.212.134.0/24
WebUI\AuthSubnetWhitelistEnabled=true
WebUI\BanDuration=3600
WebUI\CSRFProtection=true
WebUI\ClickjackingProtection=true
WebUI\CustomHTTPHeaders=
WebUI\CustomHTTPHeadersEnabled=false
WebUI\HTTPS\CertificatePath=
WebUI\HTTPS\Enabled=false
WebUI\HTTPS\KeyPath=
WebUI\HostHeaderValidation=true
WebUI\LocalHostAuth=true
WebUI\MaxAuthenticationFailCount=5
WebUI\Port=8080
WebUI\RootFolder=
WebUI\SecureCookie=true
WebUI\ServerDomains=*
WebUI\SessionTimeout=3600
WebUI\UseUPnP=false
WebUI\Username=admin

Originally created by @ghost on GitHub (Jun 14, 2021). Running v4.3.5 in a docker container using image: linuxserver/qbittorrent:latest Ever since v4.3.5 there's been a major uptick in memory usage after the WebUI gets launched. The number of torrents has not changed, nor has the configuration, all torrents have been only seeding since launch, no leeching. This is a new behavior in v.4.3.5. <img width="507" alt="Screen Shot 2021-06-14 at 3 22 01 AM" src="https://user-images.githubusercontent.com/10893911/121854354-100ce600-ccc0-11eb-8c0e-4648e4b6f46b.png"> Here's the current configuration. ``` [AutoRun] enabled=false program= [BitTorrent] Session\BTProtocol=TCP Session\Categories=@Variant(\0\0\0\b\0\0\0\0) Session\CheckingMemUsageSize=128 Session\CoalesceReadWrite=true Session\DisableAutoTMMByDefault=false Session\DisableAutoTMMTriggers\CategorySavePathChanged=false Session\DisableAutoTMMTriggers\DefaultSavePathChanged=false Session\PieceExtentAffinity=true Session\SlowTorrentsDownloadRate=1000 Session\SlowTorrentsUploadRate=1 Session\SuggestMode=true Session\Tags=[REDACTED], [REDACTED], [REDACTED] [LegalNotice] Accepted=true [Network] Cookies=@Invalid() [Preferences] Advanced\IgnoreLimitsLAN=true Advanced\IncludeOverhead=false Advanced\RecheckOnCompletion=false Advanced\trackerPort=9000 Bittorrent\DHT=false Bittorrent\LSD=false Bittorrent\MaxUploads=1000 Bittorrent\MaxUploadsPerTorrent=50 Bittorrent\PeX=false Bittorrent\uTP_rate_limited=false Connection\GlobalDLLimit=0 Connection\GlobalUPLimit=1024 Connection\PortRangeMin=[REDACTED] Connection\ResolvePeerCountries=false Connection\UPnP=false Connection\alt_speeds_on=false Downloads\DiskWriteCacheSize=1024 Downloads\PreAllocation=true Downloads\SavePath=/downloads/complete/ Downloads\SaveResumeDataInterval=5 Downloads\ScanDirsV2=@Variant(\0\0\0\x1c\0\0\0\x1\0\0\0\f\0/\0w\0\x61\0t\0\x63\0h\0\0\0\x2\0\0\0\x1) Downloads\StartInPause=false Downloads\TempPath=/downloads/incomplete/ Downloads\TempPathEnabled=true DynDNS\DomainName=changeme.dyndns.org DynDNS\Enabled=false DynDNS\Password= DynDNS\Service=0 DynDNS\Username= General\Locale= MailNotification\email= MailNotification\enabled=false MailNotification\password= MailNotification\req_auth=true MailNotification\req_ssl=false MailNotification\sender=qBittorrent_notification@example.com MailNotification\smtp_server=smtp.changeme.com MailNotification\username= Queueing\IgnoreSlowTorrents=true Queueing\MaxActiveDownloads=10 Queueing\MaxActiveTorrents=99999 Queueing\MaxActiveUploads=99999 Queueing\QueueingEnabled=true WebUI\Address=* WebUI\AlternativeUIEnabled=false WebUI\AuthSubnetWhitelist=192.168.0.0/26, 10.212.134.0/24 WebUI\AuthSubnetWhitelistEnabled=true WebUI\BanDuration=3600 WebUI\CSRFProtection=true WebUI\ClickjackingProtection=true WebUI\CustomHTTPHeaders= WebUI\CustomHTTPHeadersEnabled=false WebUI\HTTPS\CertificatePath= WebUI\HTTPS\Enabled=false WebUI\HTTPS\KeyPath= WebUI\HostHeaderValidation=true WebUI\LocalHostAuth=true WebUI\MaxAuthenticationFailCount=5 WebUI\Port=8080 WebUI\RootFolder= WebUI\SecureCookie=true WebUI\ServerDomains=* WebUI\SessionTimeout=3600 WebUI\UseUPnP=false WebUI\Username=admin ```

deekerman

2026-02-21 22:27:39 -05:00

closed this issue
added the
Invalid
label

deekerman commented

2026-02-21 22:27:50 -05:00

Author

Owner

@FranciscoPombal commented on GitHub (Jun 14, 2021):

@lps-rocks

The issue template is not optional. Please fill it in properly. See also https://github.com/qbittorrent/qBittorrent/blob/master/CONTRIBUTING.md.

@FranciscoPombal commented on GitHub (Jun 14, 2021): @lps-rocks The issue template is **not** optional. Please fill it in properly. See also https://github.com/qbittorrent/qBittorrent/blob/master/CONTRIBUTING.md.

deekerman commented

2026-02-21 22:27:53 -05:00

Author

Owner

@Invarti commented on GitHub (Jun 14, 2021):

I am also finding what appears to be a memory leak on my headless install running in an LXC container on a Proxmox host. After the service is started ram is low as expected (sub 100MB) for a dozen or so torrents. Then sometime later it starts crawling upward.

qBittorrent version: 4.3.5 installed via PPA
Operating system(s) where the issue occurs: Ubuntu 20.10 (LXC)
Qt: 5.14.2
libtorrent-rasterbar: 1.2.13.0

When left for enough time the service eventually consumes all available RAM causing the OS to sigkill the process. The logs ( /home/qbtuser/.local/share/qBittorrent/logs) contain nothing useful. Restarting the service via systemd brings everything back up but it inevitably dies again sometime later.

@Invarti commented on GitHub (Jun 14, 2021): I am also finding what appears to be a memory leak on my headless install running in an LXC container on a Proxmox host. After the service is started ram is low as expected (sub 100MB) for a dozen or so torrents. Then sometime later it starts crawling upward. - qBittorrent version: 4.3.5 installed via PPA - Operating system(s) where the issue occurs: Ubuntu 20.10 (LXC) - Qt: 5.14.2 - libtorrent-rasterbar: 1.2.13.0 When left for enough time the service eventually consumes all available RAM causing the OS to sigkill the process. The logs ( /home/qbtuser/.local/share/qBittorrent/logs) contain nothing useful. Restarting the service via systemd brings everything back up but it inevitably dies again sometime later.

deekerman commented

2026-02-21 22:27:53 -05:00

Author

Owner

@ghost commented on GitHub (Jun 15, 2021):

@lps-rocks

The issue template is not optional. Please fill it in properly. See also https://github.com/qbittorrent/qBittorrent/blob/master/CONTRIBUTING.md.

I wasn't presented a template when creating the issue, likely a browser back/forward cache issue. However the template is garbage and your response was completely asinine to assume it was done with malice. Instead of helping you track down this issue, I'm just going to swtich torrent clients and close the issue. Figure it out on your own.

@ghost commented on GitHub (Jun 15, 2021): > @lps-rocks > > The issue template is **not** optional. Please fill it in properly. See also https://github.com/qbittorrent/qBittorrent/blob/master/CONTRIBUTING.md. I wasn't presented a template when creating the issue, likely a browser back/forward cache issue. However the template is garbage and your response was completely asinine to assume it was done with malice. Instead of helping you track down this issue, I'm just going to swtich torrent clients and close the issue. Figure it out on your own.

deekerman commented

2026-02-21 22:27:53 -05:00

Author

Owner

@FranciscoPombal commented on GitHub (Jun 15, 2021):

@lps-rocks

I wasn't presented a template when creating the issue, likely a browser back/forward cache issue.

Maybe, I had no way of knowing that. I simply asked you to fill in the rest.

However the template is garbage

Feel free to open up a discussion about it/submit improvements. The issue template ensures users provide all the required information that gets asked for 99% of the time from the get-go to avoid unnecessary back-and-forth.

and your response was completely asinine to assume it was done with malice.

My response did not assume anything, its tone was neutral and I even provided a link to the contributing guidelines for convenience, because you might have genuinely missed it.

I also could have easily closed and locked the issue immediately due to not following the template, but I chose not to, to give you a second chance to provide the necessary information.

You are feeling personally attacked and acting confrontational for no reason, chill out.

Instead of helping you track down this issue, I'm just going to swtich torrent clients and close the issue. Figure it out on your own.

You do you. I don't recall the last time I could reproduce one of these supposed memory leaks. Then again, I don't use qBittorrent on Docker - maybe that's a key factor... Without further further information, we can't know if this is caused by a legitimate bug or just an issue on your end. Maybe we'll figure it out when a user with a similar setup posts here with a less confrontational attitude.

Lastly, if you do end up switching clients, I suggest you at least switch to another FOSS client, such as Deluge, Transmission, or others.
Don't use proprietary garbage like μTorrent, Tixati, BitComet, and friends.

@FranciscoPombal commented on GitHub (Jun 15, 2021): @lps-rocks > I wasn't presented a template when creating the issue, likely a browser back/forward cache issue. Maybe, I had no way of knowing that. I simply asked you to fill in the rest. > However the template is garbage Feel free to open up a discussion about it/submit improvements. The issue template ensures users provide all the required information that gets asked for 99% of the time from the get-go to avoid unnecessary back-and-forth. > and your response was completely asinine to assume it was done with malice. My response did not assume anything, its tone was neutral and I even provided a link to the contributing guidelines for convenience, because you might have genuinely missed it. I also could have easily closed and locked the issue immediately due to not following the template, but I chose not to, to give you a second chance to provide the necessary information. You are feeling personally attacked and acting confrontational for no reason, chill out. > Instead of helping you track down this issue, I'm just going to swtich torrent clients and close the issue. Figure it out on your own. You do you. I don't recall the last time I could reproduce one of these supposed memory leaks. Then again, I don't use qBittorrent on Docker - maybe that's a key factor... Without further further information, we can't know if this is caused by a legitimate bug or just an issue on your end. Maybe we'll figure it out when a user with a similar setup posts here with a less confrontational attitude. Lastly, if you do end up switching clients, I suggest you at least switch to another FOSS client, such as Deluge, Transmission, or others. Don't use proprietary garbage like μTorrent, Tixati, BitComet, and friends.

deekerman commented

2026-02-21 22:27:53 -05:00

Author

Owner

@FranciscoPombal commented on GitHub (Jun 15, 2021):

@Invarti

If you are willing to try to get to the bottom of your problem, I suggest opening another issue or discussion thread.

@FranciscoPombal commented on GitHub (Jun 15, 2021): @Invarti If you are willing to try to get to the bottom of your problem, I suggest opening another issue or discussion thread.

deekerman referenced this issue

2026-02-21 22:36:33 -05:00

Recheck multiple torrents at a time #12329

deekerman referenced this issue

2026-02-22 01:27:49 -05:00

Max active checking torrents - per drive #14814

deekerman referenced this issue

2026-02-22 02:17:07 -05:00

hashchecking on multiple disks at once at the same time #15587