Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web UI memory leak in browser #20735

Open
SvbZ3r0 opened this issue Apr 20, 2024 · 9 comments
Open

Web UI memory leak in browser #20735

SvbZ3r0 opened this issue Apr 20, 2024 · 9 comments
Labels
Performance WebUI WebUI-related issues/changes

Comments

@SvbZ3r0
Copy link

SvbZ3r0 commented Apr 20, 2024

qBittorrent & operating system versions

qBittorrent: 4.6.4
Operating system: Unraid, Docker
Docker Image: lscr.io/linuxserver/qbittorrent
Qt: ?
libtorrent-rasterbar: ?

What is the problem?

The qbittorrent web UI has a memory leak, causing open qbittorrent webpages in Chrome to slowly build up in memory until it hits 5.00GB when Chrome force closes the tab with a "Aw.. snap! Something went wrong" error message. Closing the webpage and reopening it resets the memory consumption but causes no adverse effects on performance. The speed of the memory build up is (as far as I can tell) proportional to the number of active downloads.
To be clear, there is no issue on the server end of things. This is a problem found in the client web browser. I have also tested with Edge, but not with any non Chromium browsers.

Steps to reproduce

  1. Run headless
  2. Open web UI
  3. Have some active downloads
  4. Wait for some time

Additional context

No response

Log(s) & preferences file(s)

No response

@xavier2k6 xavier2k6 added Performance WebUI WebUI-related issues/changes labels Apr 20, 2024
@Jorsher
Copy link

Jorsher commented May 24, 2024

Do you have more than one Web UI open at the same time? If so, try closing one.

@SvbZ3r0
Copy link
Author

SvbZ3r0 commented May 24, 2024

Will test when i can, but that's still a bug that needs fixing 🤷🏼‍♂️

@Jorsher
Copy link

Jorsher commented May 24, 2024

Not implying it's not a bug. In fact, I posted a bug report on the issue. Only posted here to give you a workaround if you do open more than one at a time...

@SvbZ3r0
Copy link
Author

SvbZ3r0 commented May 25, 2024

Ahhh ok. It's not like it is preventing me from using the webclient.

@SvbZ3r0
Copy link
Author

SvbZ3r0 commented May 27, 2024

@Jorsher I've checked with single web UI and with multiple tabs but have the same issue in both cases. I read #20873 and the issue linked there. Both of those seem to be issues on the host machine.
The issue here is completely constrained to the browser on the client machine. No memory leak on the server.

@Jorsher
Copy link

Jorsher commented May 27, 2024

No problem. Likely a different issue, then. I haven't noticed any memory leaks with only a single webui loaded, but will check it out. My clients have >20k torrents and shouldn't take long. Do you have any plugins active? Might want to try disabling them or open a 'private' window without them loaded to verify it's not a plugin causing the issue. I've seen this in the past.

@SvbZ3r0
Copy link
Author

SvbZ3r0 commented May 27, 2024

Mine is a completely vanilla install. I do have a post download script, but I don't see how it would cause any issues:
curl -XPOST http://server:2468/api/webhook --data-urlencode "infoHash=%I"
No modifications other than this. Incognito doesn't help.

I have notied that this issue only occurs when there are active downloads and uploads (torrents without peers don't count). I haven't been able to narrow it down any further than that.

@Jorsher
Copy link

Jorsher commented May 27, 2024

How quickly do you see it leak? I've had a small 3500 torrent Window open for a couple hours in Edge (Chromium) downloading ~40-50MB/s the entire time and it's at 80MB.

@Piccirello
Copy link
Member

This may be fixed by #21618.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Performance WebUI WebUI-related issues/changes
Projects
None yet
Development

No branches or pull requests

4 participants