1839291 - Firefox on macOS uses high CPU and Memory

Status: RESOLVED INCOMPLETE

(Core :: Graphics: WebRender, defect, P2)

Description

[Karan [:Karan]]

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

Steps to reproduce:

• Open Firefox and use as normal
• Observe reasonable memory usage initially

Actual results:

• Gradually start to see some lag
• See 3GB of RAM usage and 10% of CPU with no tabs running (unloaded through Firefox task manager)
• Keep observing and notice it slowly climb, hitting 7GB before I gave up and quit the app, indicating a potential memory leak

Expected results:

• Memory usage should not slowly increase over time

Additional Details:
M1 MacBook Pro 16" with 32GB of RAM
macOS Ventura 13.4
Firefox 114.0.1

Comment 1

[Karan [:Karan]]

Attachment: Screenshot 2023-06-20 at 14.12.43.png

Comment 2

[Karan [:Karan]]

Attachment: memory-report.json.gz

Memory report from about:memory, might provide more context.

Comment 3

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

The Bugbug bot thinks this bug should belong to the 'Core::Widget: Cocoa' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 4

[Andrew McCreight [:mccr8]]

This looks like a WebRender SWGL issue.

Main process:

2,258.95 MB (100.0%) -- explicit
├────918.89 MB (40.68%) -- gfx
│    ├──871.08 MB (38.56%) -- webrender
│    │  ├──817.27 MB (36.18%) ── swgl
[...]
├────884.65 MB (39.16%) ── heap-unclassified

1,314.05 MB (100.0%) -- gfx
└──1,314.05 MB (100.0%) -- webrender
   ├──1,286.69 MB (97.92%) -- textures
   │  ├────546.75 MB (41.61%) ── swap-chains
   │  ├────346.88 MB (26.40%) ── render-targets
   │  ├────190.00 MB (14.46%) -- texture-cache

Comment 5

[Glenn Watson [:gw]]

Lee, does the memory report offer any clues here?

Comment 6

[Lee Salzman [:lsalzman]]

I don't see anything in the memory report to specifically implicate SWGL other than that the user is running in SW-WR, but the WR/SWGL memory looks accounted for in that WR is allocating a lot of textures?

The only thing I see that maybe looks fishy is high heap-unclassified, but being unclassified, it doesn't tell us where that comes from.

It would be worth the reporter trying to run in Safe Mode to see if the memory use resolves if it is a plugin issue.

Maybe Brad is more familiar with memory usage on macOS.

Comment 7

[Brad Werth [:bradwerth]]

Thanks for filing. There are a number of surprising things about your findings. heap-unclassified memory should never get that large since we try to classify all potentially large allocations. That may mean there are a lot of small allocations happening which would be coming from repetitive processes. Tricky! Also, software WebRender isn't on by default for macOS Firefox, but of course should work without bloating memory. Did you turn it on for a particular reason that you can share?

Please help us isolate the issue by doing these things:

1. We've had a recent Bug with memory bloat from animated themes. Are you using an animated theme? If so, disable it and see if the problem is resolved. The fix for that Bug is in Firefox Nightly and will make it to Release in a few weeks.
2. Please launch Firefox in Safe Mode and report if the problem still occurs. If it does not, then the issue may be due to one of the extensions you are using.
3. Please use Firefox with a new profile for awhile and report if the problem still occurs. Among other things, a new profile will cause Firefox to use hardware WebRender since the pref that forces software WebRender will be at its default value.
4. If the problem is occurring for you after doing the above things (quite unlikely), please try to reproduce the problem using builds from mozregression. This will be time-consuming since each build will have to be run long enough to determine if the memory is bloating. How long is that for your use case?

Comment 8

[Andrew McCreight [:mccr8]]

From the memory report, it appears that they aren't using a lightweight theme.

Comment 9

[Brad Werth [:bradwerth]]

Aha, we have a heap-unclassified memory recorder built in to Nightly! https://firefox-source-docs.mozilla.org/performance/memory/dmd.html has the details. If you launch Firefox from an environment with the DMD variable set, then about:memory will allow you to save a new type of memory report that reports all untagged allocations. If you are able to do generate a report while reproducing the Bug, please attach that report to this Bug.

Comment 10

[Karan [:Karan]]

Sorry about the late response! Does software WebRender mean turning off hardware acceleration? If so, I did that to try and diagnose the issue on my own. I've since turned it back on and can report that this didn't affect anything.

1. I'm using the built-in system theme, nothing animated.
2. This would be quite tricky to do, because the memory usage goes up over time and I'm not exactly thrilled at the prospect of being without my extensions for a few days.
3. I can try this and get back to you.
4. About 5 days for the memory usage to reach a level that is clearly not right. For instance, I quite and relaunched Firefox right after filing the bug report (6 days ago) and I'm back at 4.5GB usage right now.

@bradwerth To confirm, I should run Firefox Nightly for the next few days and then check about:memory instead of going into Safe Mode with the current stable version?

Comment 11

[Brad Werth [:bradwerth]]

If this is a leak that progresses through multiple days then we need to do one thorough effort to figure out the memory leak. I propose you switch to Firefox Nightly, and follow the steps in comment 9 to generate a DMD report. Make sure that the DMD feature is working for you by generating a report right away, then relaunch and use Nightly similarly to your current methods to cause the problem to appear in Nightly. Once you've got a large amount of heap-unclassified memory in use, generate a DMD report and attach it to this Bug.

Comment 12

[Brad Werth [:bradwerth]]

It would be very helpful if you generate a DMD memory report, as detailed in comment 9. Additionally, would you please navigate to "about:support", click the "copy text to clipboard" button and then post that text as an attachment to this Bug?

Comment 13

[kharangateanoushk04]

This has been a glaring issue for me too in the last couple weeks. I can share memory info if required.

Comment 14

[Brad Werth [:bradwerth]]

(In reply to kharangateanoushk04 from comment #13)

This has been a glaring issue for me too in the last couple weeks. I can share memory info if required.

Thank you for posting. Would you follow the report instructions in comment 9 and that will give us a memory report to help find this bug.

Comment 15

[kharangateanoushk04]

(In reply to Brad Werth [:bradwerth] from comment #14)

(In reply to kharangateanoushk04 from comment #13)

This has been a glaring issue for me too in the last couple weeks. I can share memory info if required.

Thank you for posting. Would you follow the report instructions in comment 9 and that will give us a memory report to help find this bug.

Let me try to do it meanwhile here's another ss showing the potential memory leak Screenshot of activity monitor

Comment 16

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

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.