Closed Bug 1172351 Opened 7 years ago Closed 7 years ago
Firefox flickers black at >1,000,000K memory
306.94 KB, application/x-gzip
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150525141253 Steps to reproduce: Keep firefox open long enough for memory usage to hit 1,000,000K in Task Manager Actual results: Random lines appear in UI, followed by white boxes in address and search bars (Whiter than the text boxes themselves), then UI elements are replaced by black boxes, finally the entire content area (webpages) turns black, making firefox unusable until restart. Expected results: No graphical glitches should occur in firefox.
Could you please generate a text report in about:support page and attach it? Graphical issues might be caused by outdated graphic drivers, while memory usage could be related to add-ons (things like adblock plus are known to increase memory usage, for example).
Both crash reports are related to this bug. And adblock plus is only enabled on two of my tabs (One of which has been on the same page the entire time. No refreshing, no changing sites. So adblock is only being consistently used in one tab)
So, you have a graphic driver from 2012, surely it might be useful to look for an updated version. Regarding memory usage, you have a lot of add-ons, you might take a look in about:memory, click measure and check at the beginning the compartments that are taking the most memory. I'm sure Adblock plus is one of the heavy memory using add-ons (there are alternative add-ons that are said taking less memory, but regardless this kind of ad-blocking requires resources). Even if it's only enabled on some tabs, it still checks all the requests. That said, 1GB is not an absurd amount of memory for a modern browser, the Web is very different from what it was years ago. You can also browser for a while in safe mode and see if any of those add-ons could be making your browsing experience worse: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode Btw, let's first see if graphic driver update helps.
On startup, firefox takes 400-500k memory. Doubling that is bad. And crashing when it doubles is worse. I check about:memory very often. It's one of the 4 tabs I always keep open. At stable/acceptable memory usage, a few hours after opening firefox Explicit Allocations 428.65MB: js-non-window 31.71% window-objects 30.31% (gmail, youtube, kongregate, youtube, 12 tiny) heap-unclassified 9.96% head-overused 7.51% add-ons 5.98% Other Measurements: js-main-runtime 245.22MB js-main-runtime-gc-heap-committed 121.97MB decommited 69.92MB window-objects 46.27MB All other measurements are <25MB
(In reply to neopeeves from comment #3) > Both crash reports are related to this bug. One of them is an OOM crash (your system told Firefox "no, you can't have this bit of memory" and we crashed) and one of them is related to graphics. As Marco said, updating your graphics driver would possibly help with this. We also seem to be actively working on the graphics driver crashes with that signature, with two bugs already fixed and one having had a series of patches landing on Nightly (the latest being the end of last week). I don't really understand comment #5. You seem to give numbers for the 500m case, but your complaint is about the case where it takes much more than that. So really, we'd need numbers for that, wouldn't we? Can you just attach (https://bugzilla.mozilla.org/attachment.cgi?bugid=1172351&action=enter) the raw data from about:memory in that case?
As stated, firefox becomes unusable at that point. I can't check memory usage in about memory, only in task manager. Also, my graphics driver is completely up to date.
Is there a lot/some WebGL usage involved?
Component: Untriaged → Graphics
OS: Unspecified → Windows
Product: Firefox → Core
7 years ago
Not that I know of. Googled it, and it says that it's for rendering games without the use of plugins. The only game I'm running in firefox is using flash plugin.
This is good info, that helps. I'm not completely convinced this is just OOM situation, it could be something nasty happens under memory pressure. Nicolas, among other things, we're hitting the "Attempted to borrow DrawTarget without..." assert here: https://dxr.mozilla.org/mozilla-central/source/gfx/layers/d3d11/TextureD3D11.cpp#369
Looking at the stack, this is probably relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=1116812#c111
Crash report and comment 2 about:support graphics don't seem to match - we're showing basic OMTC in about:support and D3D11+ (and crash in that area) in the crash report?
From the crash reports, the machine is running a 32-bit OS, so we're limited to 2GB address space. Anytime we're over 1.5GB, we're in the danger zone for an OOM crash, or a memory-related graphics crash. There are two fronts to fight here. One is that we shouldn't be using this much memory in the first place. The other is that we should do something more graceful than flicker black, if we do approach memory limits. I'll leave the graphics stuff to Milan's team but I am curious about memory usage in general. neopeeves, next time you approach high memory usage, could you save an about:memory report and attach it here? (The full report would give us more information than comment 5)
1,150,000K memory about:memory log
During the issues with flickering, clicking "minimize memory usage" in about:memory only lowered memory by 100,000K at best, at worst there was no improvement. The attachment I just uploaded might not highlight the issue, as after I made it and used "minimize memory usage" again, memory dropped by about 300,000K; making me think that the issue was not present this time. By using "minimize memory usage" constantly when usage gets to 800-900,000K, I can lower memory to anywhere from 550,000K to 700,000K. But once memory reaches 1,000,000K, "minimize memory usage" has MUCH less of an effect, rarely going below 900,000K. If I could make a suggestion about the "gracefulness" david mentioned... On 32-bit OS systems, when memory reaches 1,000,000K, an alert appears (similar to the "do you want to stop this script" alerts) saying "You are running high on memory. Try going to about:memory and clicking "minimize memory usage" or consider restarting firefox". And at 1,500,000K, "Your memory usage is abnormally high. To prevent data loss from an unexpected crash, firefox is now saving your data and tabs, and will restart automatically. Please check your add-ons for possible memory leaks. More information can be found here [A link the the usual spiel about safe mode, adblock, etc]" By force closing firefox, the point at which graphical glitches start could be avoided. But definitely need to save an automatic data save system for this function (as well an an option to disable it). Even closing firefox normally, sometimes tabs aren't saved. So a double just in case backup when firefox makes the decision to restart would be good. Just one person losing data because of this would be bad.
(In reply to Milan Sreckovic [:milan] from comment #10) > This is good info, that helps. I'm not completely convinced this is just > OOM situation, it could be something nasty happens under memory pressure. > > Nicolas, among other things, we're hitting the "Attempted to borrow > DrawTarget without..." assert here: > https://dxr.mozilla.org/mozilla-central/source/gfx/layers/d3d11/TextureD3D11. > cpp#369 This seems to indicate that we failed to acquire the dxgi mutex on that texture when doing LockD3DTexture in TextureClientD3D11::Lock. a gfxCriticalError in there with the error handle would help understanding what's going on, but my intuition is that this operation is trying to allocate some memory and failing somewhere in the driver (or, more generally, for some oom related reason the driver gets into a state where various things start failing, including AcquireSync).
My few cents: For starters, you’re using the latest Intel 18.104.22.16869 driver (supporting hw acceleration) both for your chipset as well as the Intel G41 (and quite a few more) that recently got blocked for being itself because of some recent spikes in crash reports in bug 1116812. As an owner of such on-board chipset, the board bought brand new in Q3 2012 knowing it wasn’t the latest but glad it supported hw accel at least, I wasn’t happy to see that being blocked recently for no valid reason, as IMO the slowly increasing number of crashes in the past year or so might have other causes, which tends to get proven by all other crash and graphics related bugs like this one. I talked this over with Bas recently and as he said elsewhere, other reasons may cause FF to crash on the same signature or pointing to such bugs, unfortunately. It turned out that vsize / contiguous memory appears to be a real problem on my end, and while I’m not a coder, you might be suffering the same. My guess is you are experiencing issues like smearing and visual mismatches comparable to the screenshots posted in bug 1067470 and likely some stalling (spinning wheel) occasionally. The fact you reported this bug as occurring when over 1,000,000K memory supports that thought, as well as comment 16. To get an idea: 1,736.13 MB ── vsize 16.27 MB ── vsize-max-contiguous … is no exception here. You may also find the about:addons-memory add-on useful for monitoring this. My fear: developers will blame the driver once again and block your chipset for hw accel as well if it isn’t already (I just checked and it appears to be), while the real problem is in non-contiguous memory / vsize. Now I have to be careful, but I’d rather see people focusing on the real issue - i.e. trying to sort out why the memory management is "worse than it should be" (on this or just any graphics driver) instead of blaming chipsets involved or their drivers for their age while the problems persists. After all, graphichs hardware doesn’t change, their drivers have been there for a few years and hence coding FF is the only variable factor where even implementing some workaround might be an option, possibly even preventing other bugs afterwards. That’s also a reason I’d like to see hw accel in the G41 and possibly other chipsets enabled again because the culprit for crashes or behaviour such as what this bug was posted about likely is a different one than hw accel that may be run into after all, but only because of a faster increase of memory usage. I’m also afraid users will switch to another browser rather than buy new graphics cards or entire mortherboards when it involves integrated chipsets like the G41 as long as they keep experiencing issues like these. Now unless semeone can explain why FF is able to consume over 1,000,000K memory or increase it, even silently at night when idle, making it impossible to use or likely to crash / being unstable in the morning, and perhaps most of all, why it isn’t able able to "really" clean up memory either by clicking "Minimize memory usage" on the TS Info page or by closing all but one empty or single-tabbed FF window (i.o.w. it always requires a restart in such case) and explain a graphics driver is 100% to blame for this instead of something else, I’ll keep thinking we’re running after some facts here. It would be bad to say 1 G memory usage is normal, as (knowing this may sound painful for some) FF is just a browser, not a graphic design application, not to say 32 bits OSes should be to blame either for their max address space. In short: I’d like FF to be able to run for ages and use just as much memory after closing all windows than after (re)starting it. If that would be the case, we wouldn’t keep running into bugs like these for other causes, would we? Note: I wrote this just before comment 16 was posted and reading it, so it might be a little useless already if Milan/Nicolas already put the finger on it. Just thought it might be a waste not to post it though.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Firefox went from about 700,000K memory to 1,200,000K memory in less than a minute (I returned from the bathroom to see these black boxes and missing UI elements). Firefox is usually unusable like this, but I managed to get to my about:memory tab and save a report. After or during the time the report was being made, firefox fell to 1,000,000K memory, so I'm not sure if the problem causing the missing UI elements will be present, but there is a good chance it will be. I will add that nothing changed in that time. No new tabs were opened, nothing was reloaded, and no autorefresh websites (like facebook, which tends to add 200,000K memory just by being open) were open. A youtube video was open, but this happened after it was already fully loaded, and there were no ads in the video.
Attachment #8617614 - Attachment is obsolete: true
2,047.94 MB (100.0%) -- address-space ├──1,453.15 MB (70.96%) -- commit ├────448.76 MB (21.91%) -- reserved <-- I suspect this is graphics driver memory └────146.02 MB (07.13%) ── free  1,091.26 MB (100.0%) -- explicit ├────437.95 MB (40.13%) ── heap-unclassified Adblock Plus is active. Nick, would that explain the high heap-unclassified? (And if not, are you interested in digging in?)
I did a lot to cut down on memory taken by adblock. I removed the standard subscription and am using the no CSS one now. I also downloaded bartab heavy, to unload about 3/4 of my tabs. Currently I keep only 4 tabs open all the time (Email, youtube, about:memory, and an idle game), with an occasional 1 or 2 others. This, along with no longer keeping facebook open (Something else I think you might want to look at. Just having one facebook tab open adds about 200,000K to memory usage) HEAVILY lowered firefox's memory. From stable 900,000K down to 600-700,000K. Adblock, if I remember correctly, adds about 400 (Or was it 4,000) worth of memory leak for every page load. However, this wasn't a slow buildup. It was an immediate almost doubling of memory usage. It's also unpredictable, so I can't just turn off adblock to see if that fixes it. Firefox went a couple weeks without this glitch with adblock still on. If I had turned it off back then, I would've incorrectly thought that 2 weeks without a glitch meant that it must be adblock. So with no way to induce the glitch, we could end up with a false positive.
> Adblock Plus is active. Nick, would that explain the high heap-unclassified? Not likely. AdBlock Plus has two major effects: - Increase in JS memory usage at start-up (bug 1001426). - Increase in style-sets memory usage for every open iframe (bug 988266). Neither of these will cause high heap-unclassified. One piece of good news is that heycam just fixed the latter on trunk. My experience is that when high memory usage occurs in the presence of many enabled add-ons it's usually one of them that's at fault. Working out if this is true requires temporary selective disabling, which unfortunately can be annoying. If you are willing to do this, I'd start with Stylish, because it's sometimes caused problems in the past.
I can do that, but as I said before, this happens VERY intermittently. I could disable stylish, the problem won't appear for a month, and we might end up thinking that stylish was the cause even if it was a coincidental long period without the glitch happening. There's no real way to know if disabling an add-on worked, or if I just got a really long time of it not happening.
Have got the same trouble since FF33 or 34. Whenever the FF memory consumption reaches > 1GB, the tabs begin to flicker with black boxes and glitches until the whole FF Window is black. Have tried to deactive/delete all Addons, have tried to reset all settings, have tried to enable/disable hardware acceleration. Win7 / 32Bit / IntelCore 2 Q6600 @2,4 GHz/ 3GB RAM / ATI Radeon HD 5770 / FF38.0.5
¡Hola! Does the recently released version of Firefox https://www.mozilla.org/en-US/firefox/44.0/releasenotes/ fix this bug? Please report back. ¡Gracias!
I worked my memory up to 1,290,000K only to realize that I'm on FF43.0.1. I'll have to test it again later after updating, but at the very least, I can confirm it does still happen in 43.0.1
Okay, got FF44 and finally got around to checking it. It looks like when firefox hits 1,020,000K, it forces some kind of clearing with a higher priority than about:memory is capable of. This removes a small portion of the stuck memory that even "minimize memory usage" can't remove, lowering the usage to around 980,000K. Since this issue happens at around 1,200,000K, it seems to work at preventing the creation of the issue, though I can't test if the issue itself is gone now that I can't get my memory that high. Firefox memory leak causing high memory usage: Fixed Firefox UI flickering at high memory usage: Unknown
(In reply to neopeeves from comment #27) > Okay, got FF44 and finally got around to checking it. It looks like when > firefox hits 1,020,000K, it forces some kind of clearing with a higher > priority than about:memory is capable of. This removes a small portion of > the stuck memory that even "minimize memory usage" can't remove, lowering > the usage to around 980,000K. Since this issue happens at around 1,200,000K, > it seems to work at preventing the creation of the issue, though I can't > test if the issue itself is gone now that I can't get my memory that high. > > Firefox memory leak causing high memory usage: Fixed > Firefox UI flickering at high memory usage: Unknown OK. Let's mark this as WFM for now, and we can reopen and investigate further if it starts happening again.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WORKSFORME
The flickering was probably just the result of running out of address space. Painting uses fairly large chunks of memory at a time, either explicitly or under the hood, and instead of crashing we generally try to keep going for as long as possible. So I doubt the flickering is 'fixed', since the only way to fix it would be to just crash instead, but it seems we're doing better in terms of memory usage.
Not fixed. Just encountered it again with FF44.0.2 and fully updated plugins when firefox got up to 1,200,000K memory
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
As of 46.0.1, I've manages to get FF up to 1,900,000K memory with no problems (Although this means the high priority memory dump from 44.0.1 is no longer working). Marking as actually resolved
Status: REOPENED → RESOLVED
Closed: 7 years ago → 7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.