Tabs crash, suspending before out of memory, graphical glitches
Categories
(Core :: Memory Allocator, defect)
Tracking
()
People
(Reporter: trondsg+bugzilla+mozilla, Unassigned)
Details
Attachments
(1 file)
|
42.68 KB,
text/plain
|
Details |
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:67.0) Gecko/20100101 Firefox/67.0
Steps to reproduce:
With a few tabs open, starting with the latest upgrade (about 67.0.4), my tabs started getting "suspended" (hereafter unrecoverably erased) after a few seconds of inactivity.
To fix this insane behaviour, I disabled this in about:config.
Actual results:
Tabs either get unrecoverably erased, or they crash, or there are graphical glitches with elements disappering.
Expected results:
Because there is ample available ram, this shouldn't happen. I should be able to have opened as many tabs as I want. No "suspending". No crashing.
This happens with 400 mb free dedicated GPU memory (also there is the option for shared memory, according to task manager).
Also, there are several GBs free main memory, in addition to a large swap file.
If there is insufficient GPU memory, move textures to main memory instead of erasing the entire page from memory, so it needs to be reloaded from the server.
If there is insufficient main memory, allow windows to use the swap file, or manually cache the pages to disk.
To "suspend" a tab, is to willingly and on purpose cause data loss. It should NEVER happen. Ever. You don't erase people's data when there are several GB free memory. When reloading a tab from the server, data is often lost, due to such things as forms not submitted, or a different page sent from server (and you wanted to browse through what what on the page that you already got), or a lack of internet connection (to keep tabs with information open for later, without internet connection, is a perfectly valid use case).
This wasn't even a discussion back when computers had 64 MB of ram. No one would even think about abusing the users in such a way. I have GBs free, just leave my tabs open.
Note that when reading the changelog, and seeing that tabs get "suspended", one might reasonably think that this applies to activity on the tab, such as javascript. Not that the contents of the tab gets unrecoverably erased.
|
Reporter | |
Comment 1•5 years ago
|
||
The glitcing and then tab crashing just happened again, with 600 mb free GPU memory and 3.5 GB free main memory.
|
|
Reporter | |
Comment 2•5 years ago
|
||
I think something changed with the latest upgrade, 67.0.4, not just in 67.0.0, or I would have noticed this before. It just crashed with just 8 tabs open. Also, Firefox for Android just crashed. I send in the automated crash reports.
|
||
Comment 3•5 years ago
|
||
Could you please share the crash report generated after the crash or if you didn't receive any please check in "about:crashes" if there is any crash report displayed.
Thanks.
|
|
Reporter | |
Comment 4•5 years ago
|
||
Thank you for your reply.
These are some crash report ids displayed in about:crashes. I clicked "send in":
bp-45d2061b-f9f0-48a3-92ef-850cc0190704
bp-5cda8045-2ef7-4ab2-ae45-fcc600190704
bp-abd88af9-4a16-4c1a-9fd6-c3f010190704
bp-1e18a34c-c5c9-43f6-a95b-cd3ce0190704
bp-43809aaf-68d2-40fc-b50d-19cbc0190704
bp-cdf92149-a90b-45d4-85d1-433b90190704
bp-16ed7c52-fca3-4baf-8f94-b0f700190704
bp-649d166a-f8b7-409d-8f05-086200190704
|
||
Comment 5•5 years ago
|
||
Most of these appear to be OOM crashes, with the exception of one or two reports that have the same signature that is in Bug 1426863.
|
|
||
Comment 6•5 years ago
|
||
Assigning "Core: JavaScript Engine" component for this.
|
||
Comment 7•5 years ago
|
||
Looking at these bug reports on small OOMs, I do not understand. The bug reports seems to suggest that we have plenty of space to allocate, however we still get al these small OOM crashes from all over Firefox.
The good news is that some of these profiles have about:memory metrics reported. Does this tell us more on what is causing us to OOM while plenty of memory seems to be available?
|
||
Updated•5 years ago
|
|
||
Comment 8•5 years ago
|
||
(In reply to Nicolas B. Pierron [:nbp] from comment #7)
Looking at these bug reports on small OOMs, I do not understand. The bug reports seems to suggest that we have plenty of space to allocate, however we still get al these small OOM crashes from all over Firefox.
The good news is that some of these profiles have about:memory metrics reported. Does this tell us more on what is causing us to OOM while plenty of memory seems to be available?
It looks like Windows is telling us the pagefile is exhausted, I believe the recommendation is to use a size that is at least 1.5X the amount of RAM.
|
|
||
Comment 9•5 years ago
|
||
Eric, this seems to contradict the user report from comment 0.
Is there a component in Bugzilla where these issues are addressed?
|
|
||
Comment 10•5 years ago
|
||
(In reply to Nicolas B. Pierron [:nbp] from comment #9)
Eric, this seems to contradict the user report from comment 0.
Is there a component in Bugzilla where these issues are addressed?
Unfortunately each individual has a different idea of what "a large swap file" is. trondsg, how large is your swap file and how much physical memory do you have?
There's not a component for pagefile exhaustion, but it might make sense to move this to the Memory Allocator component. It would be nice if we could at least propagate information about what the size of the underlying allocation is, I suspect that we're failing to map a larger "chunk" than just the requested allocation.
|
|
Reporter | |
Comment 11•5 years ago
|
||
Physical memory: 8GB.
Swap file: I believe I increased this during testing by adding a swap file on a separate drive. They are currently set to:
1000 - 2500 MB
and
500 - 2000 MB
It says "recommended: 1911 MB" (this is what Windows recommends), "currently allocated: 3971 MB".
With no other large applications running, Firefox should have almost 12 GB to use, yet struggles to keep about 4 tabs opened. If it is is reporting out of memory, it must be trying to allocate an enormous block, or there is a bug in the memory allocator.
Just for your information, when Windows is actually out of memory, a bubble tooltip appears in the system tray. This doesn't happen.
I've had to switch browsers to Pale Moon because of this issue. It is really slow, but keeps the tabs open and doesn't crash, except when firefox is also running. I wonder why this happens.
|
|
||
Comment 12•5 years ago
|
||
Okay so in this situation you're not going to be able to allocate more than 4,500 MB of memory total on your system, even though you have 8GB of RAM. Windows requires enough swap space to store everything you have in memory plus some. This seems to be corroborated by having 4MB of pagefile available, 3.4GB of free memory, but still OOMing. What happens if you just let Windows use it's automatic settings?
|
|
||
Updated•5 years ago
|
|
|
||
Comment 13•5 years ago
|
||
I'm going to close this for now, feel free to reopen if you have a chance to test comment 12.
|
|
Reporter | |
Comment 14•5 years ago
|
||
I can't test right now, because I am on a different PC. I now have the reverse problem - Firefox doesn't unload tabs. The memory usage just keeps rising until the entire computer stops responding due to the extreme paging activity (no ssd). This PC only has 4 GB of ram. Note that even with 4 GB ram, it still handles far more tabs than the computer 8 gb ram before running into problems, which points to a programming defect in Firefox with regards to the reported bug. Surely the 8 GB computer should handle at least as many tabs as the 4 GB computer.
On this computer, Firefox remains responsive until the task manager shows physical memory over 90%, which is the way it should be. This is Windows 7, Firefox 73.0.1 build id 20200217142647.
Even a cold start with empty cache and 0 tabs uses 345 mb memory. What is this memory used for?
|
|
Reporter | |
Comment 15•4 years ago
|
||
I am now back on the PC with 8 GB ram. The problem is still there on the newest version of Firefox, even after increasing the page file size manually. I have set it to automatic now
"Okay so in this situation you're not going to be able to allocate more than 4,500 MB of memory total on your system, even though you have 8GB of RAM. Windows requires enough swap space to store everything you have in memory plus some"
This is nonsense. You must be confusing the page file (used for extra virtual memory) with the hibernation file (used when the pc goes into hibernation). On linux these tends to be the same file or partition, called swap, but the size requirement depends on the use case.
Even if the computer could only allocate 4 GB, you can't seriously think it's ok that Firefox needs 1 GB per tab.
It uses 1 GB for something unknown.
──1,229.83 MB (77.72%) ── heap-unclassified
|
|
Reporter | |
Comment 16•3 years ago
|
||
Description
•