Open Bug 1576829 Opened 1 year ago Updated 7 months ago

Memory leak on page refresh

Categories

(Core :: JavaScript: GC, defect, P3)

68 Branch
defect

Tracking

()

ASSIGNED
Tracking Status
firefox-esr68 --- affected
firefox70 --- fix-optional
firefox71 --- affected

People

(Reporter: enwi2, Assigned: jonco)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

Attachments

(1 file)

Attached image refresh_memory_bug.png

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

  • Open a website built with wasm using some good amount of memory. I've created this example: https://askuri.github.io/PrologBFS/oomtest/
    The example is a simple scripts built using emscripten. The code can be downloaded here: https://askuri.github.io/PrologBFS/oomtest/oomtest.zip
    I've taken a screenshot of how my memory usage develops and attached it. The freeing at the end might be caused by me closing firefox.
  • Watch your system memory increasing while pressing refresh every 15 seconds.

Actual results:

Instead of freeing memory from before the refresh, new memory is allocated. I've taken a screenshot of how my memory usage develops and attached it. The freeing at the end might be caused by me closing firefox.

Expected results:

Use the memory that was allocated before so a refresh doesn't increase memory use. This is the behaviour I observe when using Chromium.

Looks like a GC scheduling issue. I can reproduce on OS X, each refresh adds at least 200 MB to that content process. "Minimize memory usage" in about:memory fixes it.

@enwi2: if you wait a few minutes after the last reload, does memory usage go down again?

│  ├──4,540.41 MB (97.16%) -- top(https://askuri.github.io/PrologBFS/oomtest/, id=147)
│  │  ├──4,516.98 MB (96.66%) -- active/window(https://askuri.github.io/PrologBFS/oomtest/)
│  │  │  ├──4,516.54 MB (96.65%) -- js-realm(https://askuri.github.io/PrologBFS/oomtest/)
│  │  │  │  ├──4,515.32 MB (96.62%) -- classes
│  │  │  │  │  ├──4,500.00 MB (96.30%) -- class(ArrayBuffer)/objects
│  │  │  │  │  │  ├──4,500.00 MB (96.30%) ── non-heap/elements/wasm [9]
│  │  │  │  │  │  └──────0.00 MB (00.00%) ── gc-heap [9]

Yes, it goes down again after like 30 seconds.

Thanks for reporting! The test case easily reproduces. It seems like GCs happen around 60seconds after the first refresh, whether or not one periodically refreshes the whole time or not. Jon, are you aware of the scheduling heuristics here?

Flags: needinfo?(jcoppeard)

Ah, interesting, I'll take a look.

Assignee: nobody → jcoppeard
Blocks: GCScheduling
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true

Tentatively moving to GC component.

Component: Javascript: WebAssembly → JavaScript: GC
Flags: needinfo?(jcoppeard)
Priority: -- → P1
Depends on: 1579860

I worked on adding more GC triggers in bug 1579860 but it didn't fix the problem. The browser has roots that keep the memory alive so triggering more GCs doesn't help.

The next step is to try and understand where these roots are coming from.

(In reply to Jon Coppeard (:jonco) from comment #6)

The next step is to try and understand where these roots are coming from.

Jim, do you know if the devtools would provide such information?
Or can we have this information in a different way?

Jon, Can the following help you figure out the roots? https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/Hacking_Tips#Dumping_the_JavaScript_heap

Flags: needinfo?(jimb)

Jim, do you know if the devtools would provide such information?
Or can we have this information in a different way?

We don't have anything prepared to help with this. We have primitives for finding retention paths in SpiderMonkey data, but nothing that can see through cycle-collected data, which is often responsible for retaining things in the browser.

Flags: needinfo?(jimb)

This should be fixed since bug 1592598 landed. Can you check whether you're still seeing this problem?

Flags: needinfo?(enwi2)

Using Firefox Nightly 72.0a1 (2019-11-12), situation is similar to before. While refreshing every few seconds, memory usage increases while I can't see any being freed. However, GC happens some seconds after I stop refreshing. When exactly GC happens is rather "random" and happens somewhere between 5 and 30 seconds after end of refreshing.

Flags: needinfo?(enwi2)

I tried again and I can't reproduce this any more on MacOS or on Linux. On Linux the most memory I see for one process is 350MB.

Could you try and save an about:memory report and attach it to the bug, and also the contents of about:support?

Flags: needinfo?(enwi2)
Flags: needinfo?(enwi2)

(In reply to Martin Weber from comment #12)
Thanks.

Severity: normal → S4
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.