Hacker News Reader

Comment by josefresco | Hacker News Reader

I can't remember the last time Firefox crashed and I've used it daily on Windows since ... the beginning. Are most issues related to stability more common to Linux/MacOS?

View on HN

My current instability isn't crashes but with firefox is that it will just randomly "lock up". It will still respond to a click, but will take 10's to 20's seconds to respond. I have to kill and restart firefox to get it working again, but on startup it will usually take on the order of a minute or two to start actually working.

Also, more sites just don't care about having their stuff work in firefox. I use chromium for roll20, because there is just a lot of things that are just broken on firefox.

> I use chromium for roll20, because there is just a lot of things that are just broken on firefox.

Same here. I will pay for an alternative to Roll20 that works on FF. Bonus points for open source with a hosted version.

https://foundryvtt.com/ might fit the bill.

Disclaimer: I've basically never used roll20 because it's way too heavyweight for my games; I use Owlbear Rodeo instead. But I have tech-savvy DM friends who use and like Foundry

Both of those look quite interesting for my usecases (In person/occasional hybrid games with a vtt/online only - depends on my groups current location and schedule)

Thanks for the pointers!

I use Foundry VTT regularly (and develop a plugin for it). While I've never had functionality problems with Firefox, in practice, it's the main thing I keep a Chromium install around for, since on heavy scenes even Chromium barely holds up the frame rate on my laptop, and Firefox is notably worse. This is running on integrated graphics though, it's possible Firefox is fine with a more gaming-friendly setup.

I see the exact same thing. It’s frustrating because CPU, disk, memory usage, etc are all super low. The machine is idle and there I sit waiting for the first web page to load.

I use it on a mac. The only time I restart the browser are to install a browser update (I'm no the Beta channel) or when my laptop restarts. Crashes are very rare for me.

This article is about a Windows stability improvement specifically.

I'm in the same boat. Who are these people who are running out of memory? What on earth are you doing and how old is your machine?

they probably have thousands of tabs open

and extensions to hell and back

Firefox has been solid for me since the dawn of time, and I have or currently run it on Windows, Mac, Linux, and FreeBSD.

For a while it used to be kind of slow on Mac and Linux, but I think that was slow graphics calls, which points to a possible issue with the graphics driver I was using. But the last time I checked (many months ago), it was much better.

I've seen plenty of webgl content that will hard crash FF 100% of the time.

Perhaps not FFs fault, could be an underlying driver issue, but ideally web content is sandboxed enough that it can't bring down everything.

I once saw a unity web game with a bug that crashed all major browsers across multiple OSes. Go go web tech!

Even the crashes are cross-platform!

Unlike Opera 12 that could handle up to a thousand of tabs, Firefox (until 105 ??) already starts slowing down around 100.

I was pretty much forced to install the Auto Tab Discard extension, which I'm guessing was built-in in Opera 12 ??

I use Firefox with 1200+ tabs for the last, I don't know, 60 or 80 versions.

The tabs have all been visited since you last restarted firefox?

It of course depends. I typically open dozens to several hundred new tabs per session.

You don't need a lot to eventually get a crash on Firefox. All you really need is to hibernate/sleep instead of restarting, and so never restart your Firefox, and have some Twitch stream opened - the memory leaks will eventually use up all your memory, in my experience at least.

For the longest time, maybe it still happens, leaving an Ars Technica story open in a Firefox tab would gradually leak memory until RAM was exhausted.

So, you know, anyone who opens a story on Ars Technica to read later and then forgets about the tab.

I've seen YT do similar things in the past as well.

I recall a particularly strange Firefox bug on Windows where the browser would die with an out of memory error even though there were upwards of 16 GB free to use. As it turns out something was consuming large amounts of swap on the system, and this was where the out of memory condition was happening.

Here's the thing: they're not! The reason those users where crashing was because something, somewhere (possibly in the graphics stack) was reserving ton of space without using it. We had crashes on file with 20+ GiB of free physical memory which was the reason why I started looking into why a machine with so much free memory could suffer a crash.

I hope I described how this whole things work because Windows memory management is not well known and some things about it are counter-intuitive; especially if you're coming from Linux.

I can confirm this is the case. Firefox reserves tens of gigabytes and then only actually uses a few. But since those tens of unused gigabytes are still committed, nothing else on the system can use it, and Firefox (+ tons of other apps) will OOM when the total committed memory (of all applications) reaches the total amount of RAM installed.

I have 17 crashes on file (in about:crashes) that are OOMs caused by Firefox committing too much memory and not using it. My solution is to restart the browser when committed memory reaches 38GB or so, but that clears all private windows which annoys me. I shouldn't have to restart the browser so often.

Could you open a bug on our tracker, and point to those crash reports? I'm very interested in analyzing real-world scenarios where this happens to figure out where those committed areas are coming from. Our best guess is that they come from the graphics stack because we account all the memory we commit in Firefox and there's nothing missing, so wherever this is coming from it's outside of our direct control.

I actually did open up about:memory a few hours ago and now, and it looks like some growth is coming from "heap-unclassified" in the main process.

As for opening a bug on your tracker, meh but I can give you a list of report IDs:

    bp-e6392a4b-44e8-4013-a80e-1027b0221109  
    bp-dae0a056-3c6a-43ea-ad3f-5fe1a0221006  
    bp-0be1e0f7-0eca-4744-a05c-ce2030220927  
    bp-65c63eea-fb45-419d-a58a-82ef20220915  
    bp-061b6131-5ae3-4de1-a7ba-0c4950220830  
    bp-32f879a0-f76f-4a5b-bef9-f013f0220820

From the looks of it you have a minuscule page file (16MiB), that's why you're running out of commit space. I suggest setting it to auto-resize (the Windows default) which should provide a much better experience even with other applications, unless you need to keep it small because of storage concerns. Generally speaking Windows behaves very poorly with small swap files because of its inability to overcommit memory.

Firefox should not be relying on overcommit in the first place. The issue isn't that I "only" have 40GB of commit space - it's that Firefox keeps taking more and more to the point of crashing (itself and everything else I have running).

And yes, my page file had grown to 64GiB before, when I stupidly left it on automatic. There's a reason it's at 16MiB now - it's because completely turning it off disables memory compression. Not like that helps much due to the lack of overcommit.

You're assuming that Firefox is eating all your commit space, but it's not, far from it, I can see it from the crash reports. You've got other applications running and they are also fighting for it, leaving large chunks unused. Without some swap space available Windows is leaving 10+ GiB of physical memory free which it cannot use for anything else.

This is how Windows behaves by design, there's nothing we can do about it. Windows without a swap file sucks.

Funny because I just switched to Chromium and left it on for around 36 hours and my commit space is not being eaten up. Coincidence? ;)

Before, when I killed Firefox (before it crashes naturally, of course), my committed memory would drop from 38GiB to around 18GiB, so uhh, unless some other app is intentionally playing with me and syncing up its memory leaks with Firefox's existence...

(Plus, Process Hacker confirmed that all of Firefox's "Private bytes" added up to about how much committed memory got freed when I killed it. Explain how that is caused by memory fragmentation!)

This is my third conversation with a Mozilla engineer about this! Always looking forward to be proven wrong, but it looks like you just can't seem to find the problem yet. I hope one day you can. :)

> I hope one day you can. :)

It seems unlikely given this exchange, as you seem to have decided to be as unhelpful as possible.

> Before, when I killed Firefox (before it crashes naturally, of course), my committed memory would drop from 38GiB to around 18GiB, so uhh, unless some other app is intentionally playing with me and syncing up its memory leaks with Firefox's existence...

From the article:

> However, we have no control over Windows system libraries and in particular graphics drivers. One thing we noticed is that graphics drivers commit memory to make room for textures in system memory.

Guess what's going to create textures which might trigger such an issue? The browser's hardware acceleration. Guess what happens to browser's textures when the browser is killed? They're freed.

Might be a bug in Firefox, might be a bug in the crash reporter, might be a bug in the driver, might be that chromium is not using hardware acceleration.

But here you have a mozilla engineer specifically working on crashes, and instead of trying to work with them (possibly off-board) and with the data they have to diagnose the issue — because I'd assume when gsvelto talks about commit space contents that's what they see in the crash reports - you're just being a snarky asshole.

> It seems unlikely given this exchange, as you seem to have decided to be as unhelpful as possible.

I'm not being unhelpful on purpose. They are just giving me answers that do not solve my problem. My problem is "Firefox requires overcommit to run for long periods of time ... because it has a memory leak". The solution to this problem is to figure out where the memory leak is coming from, and fix it, right? Not just to add more memory, even if it is only virtual memory.

> Guess what's going to create textures which might trigger such an issue? The browser's hardware acceleration. Guess what happens to browser's textures when the browser is killed? They're freed.

You just described a memory leak, yes, the exact issue that I am experiencing.

> Might be a bug in Firefox, might be a bug in the crash reporter, might be a bug in the driver, might be that chromium is not using hardware acceleration.

Well, I don't think the crash reporter or Chromium are at fault. And I know Chromium is using hardware acceleration because if I choose the d3d11 backend then Netflix goes black in screenshots due to DRM. So, if it is a graphics issue, it's something that Firefox does and Chromium does not. Which leaves Firefox bugs, or bugs in the driver that only Firefox triggers.

> But here you have a mozilla engineer specifically working on crashes, and instead of trying to work with them (possibly off-board) and with the data they have to diagnose the issue — because I'd assume when gsvelto talks about commit space contents that's what they see in the crash reports - you're just being a snarky asshole.

I'm sorry that I came off as a snarky asshole and that wasn't really my intention. I've been dealing with this issue for months, and as a result of that there is a lack of effort from me and that probably shows. I am sorry.

I would like to perform some more experiments to figure out what the issue is, but the problem is that when Firefox runs out of memory it also crashes half the other things on my system, which makes it dangerous.

For me, Firefox slows down dramatically as it uses more memory (e.g. more tabs and windows opened), and reaches a less-than-usable state well before it has exhausted the available memory. Tab discarding - automatic or by literally closing the tabs - does seem to recover the memory used, but does not recover much of the performance (if any). My AMD 5800 and tens of gigs of memory runs into the same crushing performance blockers as my old 8GB FX-8300 machine, with virtually the same "workload" and usage profile.

Kinda the opposite of what I'd want; I usually have over 16GB more that Firefox could use if it needed, and that's once it has reached critical mass with maybe hundreds of tabs.

Its memory measurements usually look sane, so I feel like there's some data structure or algorithm that is doing something insane in the background - which is already confirmed to be the case with the History menu, particularly if you select and delete thousands of items at a time.

I had to switch from FF to Brave on macOS because FF constantly kept over utilizing the CPU, leading to bad battery life and warmer MBP. This happened on Intel and M1 chips.

Over the last year FF has gotten a lot better about not keeping my MacBook awake because of content on some random background tab that the browser thinks is multimedia content.

Circa 2021 if I wanted my MacBook to go to sleep I had 5o shut down FF first.

FWIW wasn't any better on windows.

I never had it crash on Linux. The only issue is some sites redirect you to a page saying “you must use chrome to proceed,” which is ridiculously lazy of them

In my experience the crashing happens on bloated JS heavy sites. If you don't visit those I guess it never crashes. Happens to me like 2 times a year.

Reply on news.ycombinator.com