[Linux] Youtube hangs every ten seconds after closing a long search tab due to repeated failed attempts at garbage collection
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: ke5trel, Unassigned)
References
()
Details
(Keywords: memory-leak, perf:responsiveness, regression)
STR:
- Set
dom.ipc.processCount.webIsolated = 1so the same process is reused on Ubuntu 23.10. - Visit youtube.com, perform a search and scroll down many pages through the results.
- Open a video in a new tab.
- Close the search tab.
- Move the cursor across the seek bar for 30 seconds and notice responsiveness.
At regular 10 second intervals, the page becomes unresponsive for several seconds. There is steady memory growth during this time before the delta peaks at 250MB, drops and becomes responsive again. The periodic hangs continue for hours until the process is terminated, independent of the number of tabs.
The youtube process memory never drops below 1GB, while on Windows it drops to 500MB with the same STR. Garbage collection appears to be failing on Linux and retrying over and over.
Happens with Wayland, XWayland and X11. SW-WR and HW-WR.
Performance profile:
https://share.firefox.dev/3tSFzNG
Regression window:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7c0a787fe65ac4e0f9c12cad3d9a94156c9d9ad5&tochange=4ce68ee50da2e00a53f4d9c5cc8d7e95426fd3cb
Possibly regressed by Bug 1645677.
Comment 1•2 years ago
|
||
:stransky, since you are the author of the regressor, bug 1645677, could you take a look?
For more information, please visit BugBot documentation.
Comment 2•2 years ago
|
||
(In reply to Kestrel from comment #0)
Possibly regressed by Bug 1645677.
Doesn't look much related to Bug 1645677 as this is about window hide/close. But can you try latest test build for the possible Bug 1645677 regression?
Appreciate the test build and as you predicted it still reproduces.
Bug 1785162 is memory-related but limited to Windows.
Bug 1782400 mentions the cycle collector so tentatively marking that as the next possible regressor.
Comment 4•2 years ago
|
||
I can't reproduce this. But there's nothing to hint that this would be caused by bug 1782400.
Could you attach a memory report (https://firefox-source-docs.mozilla.org/performance/memory/about_colon_memory.html)?
Comment 5•2 years ago
•
|
||
I haven't managed to reproduce on linux (and haven't tried elsewhere).
Comment 6•2 years ago
|
||
Peter, could you please assign Priority/Severity ratings to this report when you get a chance?
Comment 7•2 years ago
|
||
Unfortunately I don't think a memory report will reveal anything too useful, though it would still be good to look at one. Odds are, it'll show that the entire YouTube page is leaking. We need a narrower regression window, or if somebody can reproduce it and dig into the CC logs. (Probably not a good idea to upload CC logs here from an actual profile where you are logged in, as they can contain a lot of information, potentially.)
Comment 8•2 years ago
|
||
I'll go ahead and mark this S3. The issue sounds bad and I'd like to fix it, but the regression range points to September 2022, which is a long time ago, so I think we'd have gotten more reports if this was a common issue people were experiencing on YouTube. That being said, the standard Fission process selection process probably papers over a lot of big leaks like this.
Updated•2 years ago
|
It does not happen with dom.serviceWorkers.enabled = false and it is also no longer reproducible on the latest Nightly.
Fixed by Bug 1877596.
The author of the fix also authored Bug 1791292 in the regression window.
Description
•