Firefox developer here. There are a few ways to diagnose this, depending on your setup. If everything is frozen on Linux, it's probably the parent process that is having an issue. The "parent process" is the process that oversees all the tabs, it's the top process in a Firefox process tree, the one that has lots of children.
If our crash reporter is enabled, you can also just kill the parent process with `SIGABRT`, this will produce an entry in `about:crashes` that you can look up on restart, and submit. This will then give a link to our crash reporting front-end.
If you have `gdb` and `debuginfod` on your distro, and you're using your distro's Firefox, attach `gdb` to the parent process of Firefox, let it download symbols, and do `thread all apply bt`, this will dump the stacks of all the threads of your parent process.
If you're using one of our Firefox builds, you can use https://firefox-source-docs.mozilla.org/toolkit/crashreporte..., that will integrate with our own symbol servers. Depending on your distro this might or might not work on your distro's Firefox (some distros submit their symbols to our infra to help diagnosing crashes).
Once you have some info about the crash, you can open a ticket on your distro bug tracker, or https://bugzilla.mozilla.org/enter_bug.cgi?product=Core to reach us directly, attaching the stacks, Firefox version, crash report, about:support, or anything else that you think is relevant.
Oftentimes, those freezes (on Linux) are caused by a bug between Firefox and the desktop environment, or by graphics drivers, that kind of thing, and stacks allow narrowing down the issue greatly, sometimes it's just a package update or a configuration flip away!
Holy crap, this is the most helpful answer I've ever seen from a Firefox developer on HN. When I was having a memory exhaustion issue, I was just told "enable the page file, running without overcommit is a recipe for disaster" (looks at my 40GB of memory). I should figure out if that issue still occurs.
Running without overcommit is a recipe for disaster! Modern JITs make good use of virtual memory for both security and performance reasons.
Firefox on my laptop currently consumes almost 400GiB of virtual address space, while consuming "only" 458GiB of RSS. And that's not a bug, that's simply the browser making good use of the virtual memory system to provide significant advantages to all users on systems without overcommit disabled (which I'm guessing is 99.99% of people).
The difference in response you're seeing is simply because ta1243 is reporting a Firefox bug and you're reporting user error.
> simply because ta1243 is reporting a Firefox bug and you're reporting user error
Don't tell me Firefox needs 40GB of virtual memory to keep a tab open for longer than a couple weeks. Or that it's the JavaScript engine when closing all tabs or windows didn't free the memory, only restarting the entire browser did. It wasn't the extensions, either.
If Chromium works properly without leaking memory, and Firefox leaks memory and calls it "user error" to not have overcommit enabled, I'm going to use Chromium, simply because it actually respects my computer's resources.
Also, you're citing ways in which Chromium's V8 uses virtual memory, when V8 does not suffer from this problem. Clearly you can use virtual memory in that way without having a memory leak.
Also remember that Windows does not have unlimited overcommit like Linux does, because it has no OOM killer. So if Firefox were to use 400GiB of virtual memory, that would require the page file to take up the remainder of that.
I did have issues with my page file "automatically" growing to 64GiB with Firefox running, so maybe it literally does do this and it actually uses up hundreds of gigabytes of space on Windows machines. But that is not acceptable behavior from Firefox and it is definitely not user error to not want to give up that much space.
My laptop has a mere 32G of ram and 6G swap (currently unused but I did reboot last week)
The advice used to be 1.5*physical ram for swap back in the days when I had 4MB of ram and 170MB HDD - well under 5% of disk space Doing that today would be 20% of my disk space which seemed excessive.
Perhaps I could create a 24G swap file as a ram drive, giving me 8G of ram and 24G of swap. Why would that be better than just 32G of ram and no swap? Is it better than 40G of ram and no swap?
Yep. This was a rule of thumb which I don't think still holds with current RAM capacities.
I don't have swap on my 32G laptop, not sure it's right I guess I could use a 2G-4G swap partition when running a few XWiki instances and a Java IDE as well as a browser with several dozens of tabs instead of having the IDE frequently OOM-killed.
Well, that was just the wrong answer, since their software is supposed to be releasing memory back to the OS properly. Overcommit is just a coping mechanism, you should be addressing the root cause.
I have since enabled the page file for other reasons - LLMs demand up to 50GB of memory sometimes, and my new desktop only has 16.
The change of machine is why I should probably try Firefox again to see if it behaves.
Overcommit is allocating virtual memory without any backing. Swap is allocating physical memory backed by disk.
Overcommit is useful in some cases, for example to preallocate a large heap without immediately making it all resident. Or to allocate 'guard' pages to fight buffer overflows. On Linux, overcommit is commonly assumed and as such disabling it tends to break some programs, as it's not out of the ordinary for something to allocate 100s of GBs of virtual memory.
Read up on Windows. Windows does not do overcommit whatsoever, unless swap is enabled, in which case it only allows overcommit up to the size of the swap file.
Overcommit cannot be enabled without a swap file, whatsoever. This differs from Linux that can tend to have overcommit enabled without swap.
Yes, Windows doesn't have overcommit. (Also not with swap, since overcommit is unbacked virtual memory, which Windows still doesn't allow. The only thing it allows is disk-backed virtual memory).
But as a user, I don't care (except that I don't have to worry about an OOM killer because an allocation will just fail). The only real difference is that application developers need to be careful with allocating memory without using it, unlike on Unix-likes.
Because software on Linux runs on the assumption of overcommit, you shouldn't disable it, even though the lack of overcommit on Windows is not problematic.
It takes up disk space that I thought I could save. I have it enabled now, as a side effect of working with LLMs on my new computer that only has 16GB of memory (working on fixing that).
I still wouldn't be comfy letting Firefox fill it up, because no matter how large the page file is, your system will always crash when Firefox fills the entire thing. I do not know if my new computer will have this problem, though.
If the memory is never released back to the OS after it is done being used (or when it is not going to be used), then the browser has failed to release it back to the OS.
If our crash reporter is enabled, you can also just kill the parent process with `SIGABRT`, this will produce an entry in `about:crashes` that you can look up on restart, and submit. This will then give a link to our crash reporting front-end.
If you have `gdb` and `debuginfod` on your distro, and you're using your distro's Firefox, attach `gdb` to the parent process of Firefox, let it download symbols, and do `thread all apply bt`, this will dump the stacks of all the threads of your parent process.
If you're using one of our Firefox builds, you can use https://firefox-source-docs.mozilla.org/toolkit/crashreporte..., that will integrate with our own symbol servers. Depending on your distro this might or might not work on your distro's Firefox (some distros submit their symbols to our infra to help diagnosing crashes).
Once you have some info about the crash, you can open a ticket on your distro bug tracker, or https://bugzilla.mozilla.org/enter_bug.cgi?product=Core to reach us directly, attaching the stacks, Firefox version, crash report, about:support, or anything else that you think is relevant.
Oftentimes, those freezes (on Linux) are caused by a bug between Firefox and the desktop environment, or by graphics drivers, that kind of thing, and stacks allow narrowing down the issue greatly, sometimes it's just a package update or a configuration flip away!