Closed Bug 1804409 Opened 2 years ago Closed 2 years ago

Memory leak across page loads when using Zone.js

Categories

(Core :: DOM: Core & HTML, defect)

Firefox 107
defect

Tracking

()

RESOLVED FIXED
109 Branch
Performance Impact low
Tracking Status
firefox-esr102 --- fixed
firefox107 --- wontfix
firefox108 --- wontfix
firefox109 --- fixed

People

(Reporter: bzugmeyer, Assigned: smaug)

References

(Regression)

Details

(Keywords: perf:resource-use, regression, reproducible)

Attachments

(3 files, 2 obsolete files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:107.0) Gecko/20100101 Firefox/107.0

Steps to reproduce:

  1. 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.
  2. Add an event listener to the visualViewport object (ex: visualViewport.addEventListener('resize', () => {}))
  3. Open the Task manager (about:processes) tab and observe the memory consumption of the page
  4. 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.

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.

Component: Untriaged → Performance
Product: Firefox → Core
Attached file memory-report.json.gz

Can repro.

Look at "webIsolated=https://benoitzugmeyer.repl.co (pid 25784) " in the attached memory report

Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached file Allocation stack

Here is a memory profile https://share.firefox.dev/3FB2qjL
I'm attaching the allocation stack of the retained memory.

Attachment #9307344 - Attachment is obsolete: true
Attachment #9307345 - Attachment is obsolete: true

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.

Performance Impact: --- → low
Component: Performance → DOM: Core & HTML

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.

Component: DOM: Core & HTML → JavaScript Engine
Flags: needinfo?(bzugmeyer)

(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.

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.

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.

Flags: needinfo?(bzugmeyer)
Component: JavaScript Engine → DOM: Core & HTML

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: nobody → smaug

And thanks Benoît, this is an excellent bug report.

Regressed by: 1357785

Set release status flags based on info from the regressing bug 1357785

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.

Regressed by: visual-viewport-api-desktop
No longer regressed by: 1357785

(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.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 109 Branch

(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.

Ah, ok. I only looked at the desktop prefs file.

Seems like a pretty safe win to take on ESR. Did you want to nominate it for uplift, smaug?

Flags: needinfo?(smaug)

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.
Flags: needinfo?(smaug)
Attachment #9307516 - Flags: approval-mozilla-esr102?

Looks like the patch applies cleanly to esr102

Comment on attachment 9307516 [details]
Bug 1804409, cycle collect mVisualViewport, r=mccr8

Approved for 102.7esr.

Attachment #9307516 - Flags: approval-mozilla-esr102? → approval-mozilla-esr102+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: