Memory leak across page loads when using Zone.js
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
People
(Reporter: bzugmeyer, Assigned: smaug)
References
(Regression)
Details
(Keywords: perf:resource-use, regression, reproducible)
Attachments
(3 files, 2 obsolete files)
149.19 KB,
application/x-gzip
|
Details | |
3.75 KB,
text/plain
|
Details | |
48 bytes,
text/x-phabricator-request
|
RyanVM
:
approval-mozilla-esr102+
|
Details | Review |
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:107.0) Gecko/20100101 Firefox/107.0
Steps to reproduce:
- On a page including Zone.js (tested with Zone.js 0.10.3 and 0.12.0 (latest version at this time)), for example any angular application.
- Add an event listener to the
visualViewport
object (ex:visualViewport.addEventListener('resize', () => {})
) - Open the Task manager (about:processes) tab and observe the memory consumption of the page
- Refresh the page a few time
To better observe the issue, the page should use a bit of memory (example: render a large number of DOM nodes, or simply allocate a large Uint8Array).
Minimal example to reproduce: https://fiferox-memory-leak-when-using-zonejs.benoitzugmeyer.repl.co/
Actual results:
The memory used by the page is never reclaimed, the process memory consumption always grows
Expected results:
The memory used by the page is freed across page load.
Comment 1•2 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::Performance' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.
Comment 2•2 years ago
|
||
Comment 3•2 years ago
|
||
Can repro.
Look at "webIsolated=https://benoitzugmeyer.repl.co (pid 25784) " in the attached memory report
Comment hidden (duplicate) |
Comment hidden (duplicate) |
Comment 6•2 years ago
|
||
Here is a memory profile https://share.firefox.dev/3FB2qjL
I'm attaching the allocation stack of the retained memory.
Updated•2 years ago
|
Updated•2 years ago
|
Comment 7•2 years ago
|
||
The Performance Impact Calculator has determined this bug's performance impact to be low. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.
Comment 8•2 years ago
|
||
Is there any particular reason to think that the script isn't just keeping these typed array objects alive itself? That would be my suspicion.
Comment 9•2 years ago
|
||
(In reply to Kris Maglione [:kmag] from comment #8)
Is there any particular reason to think that the script isn't just keeping these typed array objects alive itself?
The steps to reproduce include reloading the page, so I don't think the script should be able to keep anything alive.
Assignee | ||
Comment 10•2 years ago
|
||
Yeah, I suggested moving this to DOM: Core. We shouldn't keep anything alive from the previous JS realm when reloading a page. That smells like a leak through some DOM object, but sure, could be something else too.
Reporter | ||
Comment 11•2 years ago
|
||
I concur, even if Zone.js is holding a reference to the typed array, it should still be freed after a page load. I could dig into the Zone.js code to pinpoint the code that triggers this memory leak, but I figured that you'd have better ways of investigating this.
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 12•2 years ago
•
|
||
Based on cycle collector logs, there is one DOMEventTargetHelper object keeping the previous page alive.
that object has one unknown reference to it.
That DETH's wrapper, which is also alive, tells it is VisualViewport.
https://searchfox.org/mozilla-central/search?q=symbol:F_%3CT_nsGlobalWindowInner%3E_mVisualViewport&redirect=false tells that we never ever release that object so there is a cycle window->visualviewport->wrapper->window
Patch coming
Assignee | ||
Updated•2 years ago
|
Assignee | ||
Comment 13•2 years ago
|
||
And thanks Benoît, this is an excellent bug report.
Updated•2 years ago
|
Comment 14•2 years ago
|
||
Set release status flags based on info from the regressing bug 1357785
Assignee | ||
Comment 15•2 years ago
|
||
Comment 16•2 years ago
|
||
Updated•2 years ago
|
Comment 17•2 years ago
|
||
Not that it really matters, but I think bug 1551302 is the more specific regressor, because that is where the pref was flipped for this feature.
Comment 18•2 years ago
|
||
(In reply to Florian Quèze [:florian] from comment #9)
The steps to reproduce include reloading the page, so I don't think the script should be able to keep anything alive.
Thanks. I missed that part.
Comment 19•2 years ago
|
||
bugherder |
Comment 20•2 years ago
|
||
(In reply to Andrew McCreight [:mccr8] from comment #17)
Not that it really matters, but I think bug 1551302 is the more specific regressor, because that is where the pref was flipped for this feature.
Not sure it matters, but bug 1551302 is where we turned it on for Desktop, it had been enabled on mobile for a while before that.
Comment 21•2 years ago
|
||
Ah, ok. I only looked at the desktop prefs file.
Comment 22•2 years ago
|
||
Seems like a pretty safe win to take on ESR. Did you want to nominate it for uplift, smaug?
Assignee | ||
Comment 23•2 years ago
|
||
Comment on attachment 9307516 [details]
Bug 1804409, cycle collect mVisualViewport, r=mccr8
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration: The patch fixes a rather bad memory leak in a somewhat rarely happening case.
- User impact if declined: Memory leaks take resources and make CC/GC times longer.
- Fix Landed on Version: 109
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky): Should be low risk, it is just traversing/unlinking a member variable.
Assignee | ||
Comment 24•2 years ago
|
||
Looks like the patch applies cleanly to esr102
Comment 25•2 years ago
|
||
Comment on attachment 9307516 [details]
Bug 1804409, cycle collect mVisualViewport, r=mccr8
Approved for 102.7esr.
Comment 26•2 years ago
|
||
bugherder uplift |
Description
•