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

Steps to reproduce:

System: Linux Mint 20.3 Mate 64-bit ROM LiveMedia System on i5 4GB desktop.
codecs and update to Firefox 95.0 installed. INXI report attached.
Open Firefox and open website tabs. The more websites opened the sooner the browser will HANG FROZEN. The only way out is <Alt + SysReq>REISUB reboot or cycle power.
Running Mint 18.3 with codecs and update to Firefox 87.0 NEVER HANGS ... when memory usage hits 100% the system hesitates a bit but does not freeze. Closing tabs relieves memory and system runs normally.

Actual results:

System eventually FREEZES SOLID requiring reboot. I had Thunderbird open checking package delivery status when system froze and it messed up my Thunderbird profile USB drive.

Expected results:

System should NOT FREEZE UP SOLID requiring reboot, especially not with other drive files open.

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

Could you provide a bit more information about what causes the issue here, to help us reproduce or investigate?

In particular:

• What sites seem to particularly trigger it? (if it's particular sites) and/or how many tabs seem to be required? (you mentioned it's faster with more tabs)
• How quickly does it happen?
• Does performance slowly degrade, or is it sudden?
• You mentioned memory usage being possibly-involved -- could you confirm whether that seems to be the case (e.g. by watching top or similar)?
• Assuming memory usage is indeed the issue, could you capture a memory report at about:memory (there's an "anonymize" box you can check there if you want to remove URLs from the report), and attach it here?

https://www.health.pa.gov/topics/disease/coronavirus/Pages/Cases.aspx

This site was behaving erratically and so I closed it and opened the System Monitor. I reopened the site and luckily the data for the "Covid Dashboard" was loading slowly and I was just able to do a screen dump of the monitor and close the tab as it was beginning to hang. As you can see from the dump, it was right at the limit of memory. It should be noted that there is no warning whatsoever from the system that it is on the verge of total freeze hangup. When it does hang, I am still able to do a <Hold ALT><SysReq><REISUB> to reboot the system without powering down.

Blessings Team!
Sorry it has taken me so long to reply ...
The problem is DEFINITELY 'running out of memory'. As mentioned, this is a LiveMedia system running from ROM so it is memory intensive. The machine only has 4GB and 60% is used just to boot.
I was finally able to capture a screen dump for one case and I will attempt to attach it??? {SUCCESS! See above)

There are various memory intensive sites that I open frequently:
https://www.wunderground.com/wundermap?lat=40.2&lon=-77.19
https://www.google.com/maps <-- especially with "Street View" active
Any video open with "Picture-In-Picture" - dragging the target picture across the window is "instant death"

It would be nice to get an "Out of Memory" warning in this situation, but basically there is just not enough memory in this system to accomplish the tasks I am performing.

Many thanks to all of the team for supporting Linux for all of us.
Blessings in abundance, all the best, & stay healthy!
Art in Carlisle, PA USA

https://www.health.pa.gov/topics/disease/coronavirus/Pages/Cases.aspx is certainly heavyweight.
The map which has 'confirmed cases' and such uses lots of memory and CPU time (there is some javascript timer running on that page all the time).

https://share.firefox.dev/3BNZU5Z

But I see other browsers using quite similar amount memory and cpu. It is just that the particular site(s) is/are heavy.

toshi, is there a bug open to crash a badly behaving tab before the system is really OOM?

(In reply to Olli Pettay [:smaug] from comment #5)

toshi, is there a bug open to crash a badly behaving tab before the system is really OOM?

No bugs I can think of. If there are background tabs when the memory usage reaches 100%, the tab unloading feature is expected to mitigate the situation, but if the active tab keep consuming the memory, it will not help.

Hi, I've been plagued by this issue for years, it's good to see that it has been reported. What I currently do is start firefox in its own systemd user .scope unit, allowing me to systemctl --user set-property my-firefox.scope MemoryHigh=11.8G MemoryMax=12G before firefox grinds my system to a halt. Then I switch back into firefox, go to about:memory and manually trigger a GC, CC and memory minimization. I think it would be a nice fix if firefox could measure its memory consumption and trigger these itself as it becomes more scarce, perhaps while also monitoring the memory allowed for it by systemd, because systemd slows memory allocations once it hits MemoryHigh, grinding firefox to a halt.

I start it as follows, in case anyone needs it:

#!/bin/sh
exec systemd-run --unit=my-firefox --user --scope -p MemoryHigh=10G -p MemoryMax=10.5G -p MemorySwapMax=0 firefox```

I just went OOM again after sending this, but then again I actually made this account to complain about this issue. ;)

Importantly, and I forgot to mention, when this happens and I manually collect garbage, I notice Firefox's memory usage going down from 11G to maybe 7G, so the real fix in my opinion would be running the garbage collector more often or improving it where necessary.

Here are more "sufferers" from this bug ... it is NOT "UNCONFIRMED" ... it is just rare and mostly only found in machines with small memory.

From the Linux Mint Forums website ...

Re: Is there a program (or setting) to prevent my system from freezing caused by tabs with videos playing?

Main topic and original poster: https://forums.linuxmint.com/viewtopic.php?f=90&t=370709

Additional poster with the problem: https://forums.linuxmint.com/viewtopic.php?p=2174746#p2174746

The above comments #7/#8 by Moritz Wilhelmy are VERY informative about this bug.

Blessings in abundance, all the best!
Art in Carlisle PA USA

Blessings!

I have upgraded my LiveMedia ROM USB thumbdrive to Firefox 98.0.2 (64-bit) Mozilla Firefox for Linux Mint (mint-1.0) and this newer version is FAR superior to v95 with respect to small memory systems. To test it I heavily loaded it with several memory intensive pages as previously, along with loading my Thunderbird email profile (on a separate TEST-ONLY thumbdrive) and System Monitor, and pushed the system into the 95 - 98% memory usage range.

Two important observations - 1) memory is released much more frequently and in larger blocks, which helps tremendously in preventing hitting the limit. I pushed it right into 100% usage and THOUGHT it did the FREEZE of the system ... BUT ... although the System Monitor and the Firefox window froze and discontinued updating, 2) the MOUSE didn't 'totally' freeze. However, it got INCREDIBLY SLOW. It took me about 5 minutes to nudge the mouse cursor over a tab CLOSE button, and after clicking it quite a few times (with no apparent affect) I started trying to move it to a different tab. After about 20 seconds, everything broke free - a couple of tabs closed, memory usage dropped below 80%, and the whole system was operational again.

What happened to the "Nearing Memory Limit Warning" pop-up ???

Although this was a good situation in that I did not have to power down the system to recover, what happened to the Modal pop-up I have seen years ago in previous versions of Mint that warned of imminent memory problems? In this case, it would certainly be valuable if there was a warning at about 95% memory usage to prevent running out of memory causing problems. Is the disappearance of this WARNING (at least in Thunderbird) a different bug that should be addressed? Is this a kernel problem?

Thank you for all the support of this excellent product.

Blessings in abundance, all the best ...
Art in Carlisle, PA USA

Feels like maybe there's something here where we can avoid breaking linux when we use lots of memory? Is Chrome less likely to do this to the OS?

I'm not familiar with the Firefox codebase. So from my cozy armchair I would propose this:

On every call to memory allocation functions (at least every other time, when either large objects are allocated or a certain total since the last checkup has been allocated):

a) keep track of free, total available and used memory (minus filesystem caches) on the system in a variable. If firefox is running from a systemd unit, discover the amount of memory this unit is allowed to use and use these values instead.

b) keep ratio of memory used by firefox divided by total used memory on the system. When this value goes over a certain threshold (e.g. 0.7), trigger emergency GC. Maybe it makes sense to also factor in some of the other variables.

For systems with swap partitions, there should probably be some logic to pin important pages to RAM so performance doesn't degrade once memory runs low. Maybe this is useful: https://stackoverflow.com/questions/12520499/linux-how-to-lock-the-pages-of-a-process-in-memory

This is starting to sound like a good project for a motivated student to work on during GSoC.

Sorry for blasting in with no actual code, but I see no real attempts at developing an actual software solution or even just discsussion about the problem. Would love to read the thoughts of actual developers on the subject of memory allocation in Firefox.

I'm not familiar with the Firefox codebase...sound like a good project for a motivated student to work on during GSoC...blasting in with no actual code...I see no real attempts at developing an actual software solution

https://bugzilla.mozilla.org/show_bug.cgi?id=1532955 which had to be disabled because of (at the very least) https://bugzilla.mozilla.org/show_bug.cgi?id=1780058

See also https://bugzilla.mozilla.org/show_bug.cgi?id=1532955#c14 and the follow-ups there for other suggestions that don't actually work well.

The real problem is that if this kind of detection misfires, it will crater performance too, and it's not trivial to measure whether any of these measures improve the user experience and make it worse (overall, let alone for outliers), because dropping caches or unloading pages at the wrong time also worsens the user experience just as much as being slow does.

Combine this with Linux being quite diverse with ZFS, etc having different ideas about memory allocation, systemd scopes, etc, and there's ample opportunity to go wrong.