Open Bug 1774027 Opened 2 years ago Updated 1 year ago

macOS memory leak

Categories

(Core :: Widget: Cocoa, defect, P3)

Firefox 101
defect

Tracking

()

UNCONFIRMED

People

(Reporter: austinlunbeck, Unassigned)

Details

(Keywords: perf)

Attachments

(5 files)

Attached file Archive.zip

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.5 Safari/605.1.15

Steps to reproduce:

Have Firefox open for a randomly but always large period of time (hours / days). As soon as it's open it slowly creeps up I can actively see as I'm writing this it's climbed 1b. (copy of about:support and memory report included inside Archive.zip)

Actual results:

macOS popup saying Firefox was using over 100gb of memory

Expected results:

Firefox shouldn't have a memory leak that uses all my ram and apparently large amount of virtual storage.

Note I was wrong while writing it actually jumped from 3.3gb to 7.8gb. Please lmk if there's anything I can do to help fix this bug as it's been happening for months. I have switched to safari and back a few times the issue is always persistent. I have double checked and everything is fully updated (Firefox and macOS)

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.

Component: Untriaged → Widget: Cocoa
Product: Firefox → Core

Could you follow the steps at https://firefox-source-docs.mozilla.org/performance/reporting_a_performance_problem.html to collect a Firefox profile for us? This should help us pinpoint what might be going on.

Can you try running Firefox in Troubleshoot Mode (Help > Troubleshoot Mode...) and let us know if you're still able to reproduce?

Do you have a custom pointer size or color set in System Settings?

Severity: -- → S3
Flags: needinfo?(austinlunbeck)
Keywords: perf
Priority: -- → P3

Here's a link to the profile thing I couldn't use the sites upload since it was considerably larger than the max of 10MB.

https://drive.google.com/file/d/1LKDw2yRzzjm8coxp_BXK_dczFwPFuzjD/view?usp=sharing

The issue isn't the easiest to replicate because it can be very inconsistent. I did have it slowly creep when I took that profile thing. Once I finished and then tried the troubleshoot the issue didn't occur and now isn't occurring outside of troubleshoot mode. The issue is still persisting just hard to really know when it will happen as I said hours to days. I'll check troubleshooting mode by just using the browser with it on.

I when into all of macOS mouse settings nothing is not stock. I have a Logitech mouse with a persistent settings ability that I have the dpi set aka no need to change anything thus nothing changed.

Flags: needinfo?(austinlunbeck)

Markus, would you mind taking a look at the profile?

Flags: needinfo?(mstange.moz)

Any information about the profile? Issue still happening.

Hmm, unfortunately I can't see the reason for the memory increase in the profile.

What stands out in the profile is that the compositor is compositing at full frame rate for the entire recorded duration. Usually that's due to some animation or video playing. But on the various content main threads I can't find any indications of such an animation. There's one foreground tab which has a 24ms setInterval running the entire time, but it's not doing any painting. However, in the parent process, there is indeed an indication of an image animation, maybe there's a tab with an animated gif favicon or a bookmark in the bookmarks toolbar with an animated icon.

During profiling there is some expected memory increase, because the profile data needs to be stored somewhere. That's especially the case if the profiler is capturing screenshots (can be turned off on about:profiling).

So yeah, I'm not sure what to do next.

In the past we've had reports of leaked GPU memory from users of AMD GPUs. But this is an M1 machine.

Flags: needinfo?(mstange.moz)

So is there any different thing I can do or maybe a particular website you'd like me to visit while this issue is occurring (so you know what should be happening?).

Same issue at work here, when opening Firefox it jumps straight to 2G of ram and continues rising until it reaches 60GB at which point MacOS stops the process. It happened on two different MacOS machines. Let me know if any information could help.

@cesar, could you make sure you're on the latest macOS version and then follow the same steps/questions from Comment 3?

Flags: needinfo?(cesar)

I have a similar issue, on a MacBook Pro (Intel), except:

  • It happens every day, many times a day.
  • I've endured the effect for about 2 years. I'm on the Firefox beta channel.
  • I've seen it creep up to the ~60GB level, and then crash the system. Nowadays for me it doesn't reach 60GB because I don't have that much disk space. Instead, swap files fills the disk until it's full, and if I'm unlucky it is necessary to reboot MacOS from that point onwards (because MacOS can't delete files when the disk is full (as silly as that sounds), but it seems to be able to delete swap files during boot).
  • I have 16GB RAM, and was thinking of buying a 24GB Macbook but concluded that 24GB isn't enough to run Firefox smoothly any more.
  • Although I am running other applications, Firefox has more than half the RAM devoted to it, and it's not enough.
  • Stuttering/jank happens all the time, 1 or more second pauses what feels like every 10 seconds or so, and it might be caused by this, and minute-long pauses every so often. The experience is not smooth at all.
  • about:memory "Minimize memory usage" always frees enough memory to fix the problem (for a while), so it appears that the excessive memory usage is not actually necessary for the currently active pages to function. The only problem with using this button is Firefox is stalled while processing it.
  • about:performance does not show large amounts used in the memory column for any row. about:performance total is consistently <1GB.
  • Data suggests it's not caused by having too many tabs, at least not directly. (about:memory frees the memory and doesn't discard tabs, which is why the problem doesn't look like it's caused by too many tabs.)
  • Data suggests it's not due to site JavaScript code storing large amounts of data in variables.
  • Data suggests it's not caused (only) by images, because a text-only site can also cause large memory usage.
  • I do have many add-ons, and I'm suspicious of them. But the fact that about:memory always frees enough memory causes me to think it probably isn't memory used by an add-on either, unless those have garbage-collection triggered events.

Note: Typos in this report may be caused by FF pauses that occur about every 10 seconds while typing...

I'm amused, but in a sad way, when seeing old reports where people are surprised to see FF using a whole GB. When I open a tab the memory usage may go up by 2GB just from one tab, and that's even when using text-only sites like news.ycombinator.com. If I actually read a few comment threads, on that site, RAM usage can go up 10GB. I would be pleased if it would stay at 10GB.

Just in case it helps the diagnosis, I'll list some factors in my usage.

When I had more disk space, in the worst case I saw it reach 67GB in the iStat Menus monitor. However, that shows larger values than Activity Monitor, so they must be measuring differently. The difference is significant: 16GB in iStat vs 9GB in AM. Based on figures I see at other times, I would guess on that 67GB iStat occasion Activity Monitor would have shown maybe 40GB. My speculation: Perhaps one shows uncompressed and the other shows compressed swap; or perhaps they show memory-mapped files differently. As a reference point, I have 16GB RAM.

I have noticed levels close to 67GB only occurred (I think) with a Telegram web tab open. This has occurred several times with Telegram; it wasn't a one-off. (Which is why I installed the app instead of using the web version now).

Perhaps there's a particular problem with Telegram-web, but I mention it because it might be useful to have a prominent reproducer for diagnosing the more general issue with other sites. Just now when I opened Telegram web for the first time in a while, Firefox started to grow apparent memory usage by 0.5 to 1 GB per second for the first 10GB or so, and then carried on growing intermittently after that. But on subsequent reloads it was less reliable: Re-visiting the page after closing the tab didn't grow memory usage much, but Control-Shift-R caused another spike of 4GB memory usage just now.

With other web activity, Firefox spikes in the 25-35GB range (as shown in iStat Menus measure). Even though the number may be misleading (as compressed in-RAM swap may be occurring, and Activity Monitor shows a smaller value), it is swapping to SSD, because it shows the swap space increasing and SSD free space decreasing. At ~35GB for Firefox (shown in iStat Menus), it will have consumed all of my 20GB SSD free space in swap files to accomodate this.

The memory usage fluctuates wildly. It will seem to garbage collect sometimes of its own accord, and shrink down to some level not much more than when Firefox was started. When it will do this is not entirely predictable. There isn't an obvious numerical threshold when it will decide to start garbage collecting. Sometimes it grows until I run out of disk space for swap. The increase is usually slow, but sometimes even opening a single new tab increases memory usage by >1GB, and sometimes reported usage grows by >1GB per second. Shrinkage is also <1GB per second sometimes.

Clicking among a few articles and opening a small number of tabs, even when they are all on the text-only site news.ycombinator.com, fewer than 10 tabs open (but presumably having visited more than 10) can raise memory usage by >10GB sometimes. Because this can occur when the tabs are all text-only, it means the RAM usage cannot be attributed to large images. (Note there is some JavaScript on that site, but I don't think there's a lot).

During all this, despite many GB of memory usage, sometimes more than my 16GB of RAM, there is nothing large in the memory column of about:performance. Right now Task Manager itself is the largest at 272.1MB; the second highest (sorted by memory) is 44.1MB for a Reddit page, and the third highest item is 11.2 MB. The total when all of them are added comes to less than 1GB. It's always like that: The huge and fluctuating memory usage of Firefox doesn't show up in about:performance for any page.

I do have a lot of tabs. However, that doesn't explain the problem (please don't dismiss my report with "don't use so many tabs" as many people do when I've brought up the issue elsewhere). After Firefox is restarted, with all my tabs (1 per window will be active), the memory usage is stable and tolerable for a while. I use Auto Tab Discard, so in principle the memory used by active tabs after that should be not much more than the amount after restarting. But it actually goes up to intolerable levels. This continues even if I explicitly discard all tabs that are not visible.

However, opening about:memory and clicking "Minimize memory usage" always fixes the problem, shrinking the memory usage of Firefox to tolerable levels (for a while), without needing to restart anything.

Because about:memory always works, I feel confident saying the high memory usage is not really necessary for the pages to function - and this implies it is probably not JavaScript data in application code either (unless they have some fancy weak-hash stuff going on). The rate at which "Minimize memory usage" shrinks memory usage varies, from about 1GB per second at best, down to about 0.05GB per second. Typically I see about 100MB/s disk reading by Firefox during this.

Because "Minimise memory usage" always works (and doesn't discard tabs), and because text-only news.ycombinator.com triggers high usage as well, the terribly high memory usage looks to me like: (1) a garbage collection or cache problem, (2) not data necessary for the pages to function (except maybe temporarily), (3) not caused by JavaScript data leaks in application code, (4) not caused by bloated application code (5) not caused by images, and (6) not caused by too many tabs, (7) not counted in whatever about:performance uses, and (8) it could be reduced to stay within available spare RAM at all times.

Because about:memory consistently recovers the size to a usable level, I wonder if some cache or GC heuristic is using the wrong target size when deciding how much memory to allocate. I wonder if MacOS compressed-swap is somehow fooling its heuristic.

If the about:memory "Minimize memory usage" button could be auto-clicked every 10 seconds, this is what I'd do, but it has one problem: Firefox is unresponsive while it's minimizing memory usage, which can take a while.

Because of this problem I have learned to look at memory usage every so often when using Firefox, or if it seems to be stuttering more than usual, and go to about:memory and click Minimize to sort it out for a while. Sometimes I'm surprised at how soon I've needed to do this after the previous time.

A very annoying side effect is constant stuttering/jank. E.g. while typing this text, every so often the cursor freezes for a few seconds. When browsing any page, each time I do a trackpad scroll gesture, scrolling freezes for a few seconds, then instantly jumps to where it should be. These stalls happen what feels like every ~10 seconds of usage, so they are very noticable and detrimental to the experience. I don't know for sure that these pauses are caused by memory usage going into swap. They might be a separate problem. But because I also experience pauses like this often while I see the memory usage dropping, for long enough to bring up the "spinning beach ball" on MacOS, and FF showing as unresponsive in iStat Menus memory monitor, they might have the same underlying cause.

I response to #c10, I can't update to the latest MacOS version. My MBP isn't new enough (it's a late 2013 model), and I daren't risk updating to the latest MacOS that it could run in theory, because of reports of brickage on this model. So I am running Catalina 10.15.7. The issue occurred with earlier Catalina; I don't recall if it occurred pre 10.15. I'm a reasonably experienced dev (though on Linux not MacOS) and willing to help diagnose if someone can provide useful guidance that isn't too time consuming to follow, or if someone wants to work through it with me (pairing style), but Firefox being as large as it is, finding a spare day to learn enough of the codebase to dive into it and find the problem myself isn't feasible.

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 auto_nag documentation.

Flags: needinfo?(cesar)

I have now also randomly encountered this leak. I have narrowed it down to whether or not I have a Gitlab tab open... I am attached a set of 4 memory profiles recorded using about:memory.

The first, memory-report_NO_LEAK.json.gz is where the Gitlab tab is closed. Firefox memory is stable.

The next 3, memory-report_LEAK_START.json.gz, LEAK_CONTINUE, and STILL_LEAKING are memory reports (taken in that order) while the offending tab is open. During this time Firefox continuously leaks, and macOS activity monitory reports memory usage monotonically increasing.

I can also confirm that this survives the close and reopen test. Closing the Gitlab tab immediately frees the memory, and Firefox memory usage is stable. Re-opening the tab, and Firefox leaks again immediately.

I hope this helps pinpoint the bug...

Firefox memory profile while Gitlab tab is closed. Firefox does not leak memory

Gitlab tab is opened. Firefox starts leaking memory.

Second timepoint of Firefox leaking.

Also something to note, I don't believe this is caused by Add-ons. I manually disabled all of my Add-ons and quit and relaunched Firefox, and the leak still occurs with the same trigger as before.

Actually, after doing some more testing I don't believe it is the Gitlab tab itself that is the issue. Rather, it has to do with having multiple windows open in multiple virtual desktops. I originally had the Gitlab tab open in a second window on a second virtual desktop.

I can reliably reproduce the leak via:

  1. Create a new Firefox window in desktop 1.
  2. Create a second virtual desktop (desktop 2).
  3. Switch to desktop 2, and open a new Firefox window in it.
  4. The memory leak fires.

Note that any of the following will stop the leak and free the memory:

  1. Closing the window in either desktop 1 or 2.
  2. Consolidating all windows to a single desktop. It does not matter if you move window 2 to desktop 1 or window 1 to desktop 2.
  3. Closing either window.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: