1643064 - Memory leak in foreground webworker

Status: NEW

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

Description

[Matt Rossman]

Attachment: Activity monitor after running the example for a few minutes

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

Steps to reproduce:

1. Clone the brfv5-browser project repository (I've provided the specific commit):
   https://github.com/Tastenkunst/brfv5-browser/tree/d77ada73cac828a04b0ae6b0b5f219cf12f62296

2. Start a live server in the project (e.g. on port 5500)

3. Navigate to the minimal__webworker__track_one_face.html page on the server

4. Let the demo run in the foreground for a few minutes

Actual results:

Firefox's webworker process gradually gains more and more memory (I've seen multiple gigabytes) causing the page to get slower and slower, and eventually unresponsive. I also noticed that if I switch tabs, the webworker process will start releasing memory back to acceptable levels.

In Google Chrome, the webworker does not keep consuming memory in this way, suggesting that it is a Firefox bug rather than a bug with this specific example.

Expected results:

The webworker should release unused memory while running in the foreground. Firefox should not degrade the performance of the web app.

Comment 1

[Matt Rossman]

I just reproduced this on a fresh install of Firefox Nightly as well.

Comment 2

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Hi,

Thanks for the report. Could you please submit a memory report?

Here are the steps to create it from about:memory

1. Wait until Firefox is consuming a large amount of memory
2. Enter about:memory in the URL bar and press enter
3. Click "Measure and save" (optionally with "anonymize" checked to hide URLs, although this will likely make it more difficult for us to figure out which site, if any, is causing the leak)
4. Save the memory report somewhere
5. Attach the report to this bug

Can you record a performance profile? The instructions in https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Reporting_a_Performance_Problem should work if it's usable initially and then hangs for a bit; otherwise, the steps at https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Profiling_with_the_Built-in_Profiler#Profiling_Firefox_Startup would help to profile startup itself (for "the add-on", read "the builtin profiler", see instructions for enabling that on the first page)

Also, could you please post your about:support text?

Best,

Clara

Comment 3

[Matt Rossman]

Attachment: Memory report (MacOS, Firefox Nightly)

"Firefox NightlyCP Web Content" (which I presume to be the webworker, as it continued to grow in size) was using up around 2.4 GB of memory on my system when I captured this report.

Comment 4

[Matt Rossman]

Attachment: about:support text

Comment 5

[Matt Rossman]

Here is a performance profile capture when "Firefox NightlyCP Web Content" was using just over 2 GB of memory on my system:

https://share.firefox.dev/2Yy7Vsy

Comment 6

[Clara Guerrero ( Need Info Brindusa Tot Please)]

Thanks for the additional attachments!

I will move this over to a component so developers can take a look over it. If is not the correct component please feel free to change it to an appropriate one.

Best regards, Clara.

Comment 7

[:Harald Kirschner :digitarald]

mrossman, just to confirm the right component: Did you have DevTools open (it doesn't sound like it)?

Comment 8

[Matt Rossman]

I just reproduced it without DevTools open (I don't think I had it open when I captured those reports either).

Comment 9

[:Harald Kirschner :digitarald]

Thank you. Performance is a better component then.

Comment 10

[Markus Stange [:mstange]]

The memory report shows 2.2GB taken up by ArrayBuffers:

Web Content (pid 21057)
Explicit Allocations

2,458.44 MB (100.0%) -- explicit
├──2,397.48 MB (97.52%) -- workers/workers(localhost)/worker(./js/worker/setup__worker.js, 0x159e4a000)
│  ├──2,394.80 MB (97.41%) -- zone(0x1105bb000)
│  │  ├──2,393.97 MB (97.38%) -- realm(web-worker)
│  │  │  ├──2,393.63 MB (97.36%) -- classes
│  │  │  │  ├──2,388.87 MB (97.17%) -- class(ArrayBuffer)/objects
│  │  │  │  │  ├──2,248.71 MB (91.47%) ── malloc-heap/elements/normal

Moving to GC.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:jonco, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 12

[Jon Coppeard (:jonco)]

It's possible that this is the same issue as bug 1407691.