1172351 - Firefox flickers black at >1,000,000K memory

Status: RESOLVED WORKSFORME

(Core :: Graphics, defect)

Description

[neopeeves]

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.

Comment 1

[Marco Bonardo [:mak]]

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).

Comment 2

[neopeeves]

Application Basics
------------------

Name: Firefox
Version: 38.0.5
Build ID: 20150525141253
Update Channel: release
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0
Multiprocess Windows: 0/1 (default: false)

Crash Reports for the Last 3 Days
---------------------------------

Report ID: bp-86af5057-6543-4394-bf31-68a6d2150606
Submitted: 2 days ago

Report ID: bp-61e3ed41-e169-422d-8147-379ed2150605
Submitted: 3 days ago

All Crash Reports

Extensions
----------

Name: Adblock Plus
Version: 2.6.9.1-signed
Enabled: true
ID: {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}

Name: BarTab Heavy
Version: 3.2.1.1-signed
Enabled: true
ID: [e-mail]

Name: bug489729(Disable detach and tear off tab)
Version: 2.1.1-signed
Enabled: true
ID: bug489729@alice0775

Name: Classic Theme Restorer
Version: 1.3.2.1-signed
Enabled: true
ID: ClassicThemeRestorer@ArisT2Noia4dev

Name: F.B. Purity - Cleans Up Facebook
Version: 12.8.0
Enabled: true
ID: [e-mail]

Name: Fierr
Version: 1.0.10.0.1-signed
Enabled: true
ID: lolifoxFierrMOD@ArturOsinski-Virtual_ManPL

Name: Hide Unwanted Results of Google Search
Version: 1.5.2.1-signed
Enabled: true
ID: jid0-TpZJ4wPImlT1zIqfw58bD9vOeWQ@jetpack

Name: NextVid Stopper for YouTube
Version: 1.1.1-signed
Enabled: true
ID: jid1-8tHTvv1Wsu98MQ@jetpack

Name: Stylish
Version: 2.0.2.1-signed
Enabled: true
ID: {46551EC9-40F0-4e47-8E18-8E5CF550CFB8}

Name: Video Blocker
Version: 1.0.0.1-signed
Enabled: true
ID: jid1-3OQ5HY7YsLBV7Q@jetpack

Name: BehindTheOverlay
Version: 0.1.1.1-signed
Enabled: false
ID: jid1-Y3WfE7td45aWDw@jetpack

Name: Flashblock
Version: 1.5.18.1-signed
Enabled: false
ID: {3d7eb24f-2740-49df-8937-200b1cc08f8a}

Name: FrankerFaceZ
Version: 1.55
Enabled: false
ID: jid1-snHdAu6px3p0jA@jetpack

Name: Greasemonkey
Version: 3.2
Enabled: false
ID: {e4a8a97b-f2ed-450b-b12d-ee082ba24781}

Name: NoScript
Version: 2.6.9.26
Enabled: false
ID: {73a6fe31-595d-460b-a920-fcc0f8843232}

Name: Status-4-Evar
Version: 2015.02.06.23.1-signed
Enabled: false
ID: [e-mail]

Name: Youtube Feed Cleaner
Version: 0.75
Enabled: false
ID: jid1-SFLtLoBERr5i6A@jetpack

Name: YouTube High Definition
Version: 38.0
Enabled: false
ID: {7b1bf0b6-a1b9-42b0-b75d-252036438bdc}

Graphics
--------

Adapter Description: Mobile Intel(R) 4 Series Express Chipset Family
Adapter Drivers: igdumdx32 igd10umd32
Adapter RAM: Unknown
ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 100
Device ID: 0x2a42
DirectWrite Enabled: false (6.2.9200.17292)
Driver Date: 10-4-2012
Driver Version: 8.15.10.2869
GPU #2 Active: false
GPU Accelerated Windows: 0/1 Basic (OMTC)
Subsys ID: 02aa1028
Vendor ID: 0x8086
WebGL Renderer: Google Inc. -- ANGLE (Mobile Intel(R) 4 Series Express Chipset Family Direct3D9Ex vs_3_0 ps_3_0)
windowLayerManagerRemote: true
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Important Modified Preferences
------------------------------

accessibility.typeaheadfind.flashBar: 0
browser.cache.disk.capacity: 51200
browser.cache.disk.smart_size.enabled: false
browser.cache.disk.smart_size.first_run: false
browser.cache.disk.smart_size.use_old_max: false
browser.cache.frecency_experiment: 3
browser.download.importedFromSqlite: true
browser.download.manager.alertOnEXEOpen: false
browser.download.useDownloadDir: false
browser.fixup.domainwhitelist.router: true
browser.places.smartBookmarksVersion: 7
browser.search.suggest.enabled: false
browser.search.useDBForOrder: true
browser.sessionstore.upgradeBackup.latestBuildID: 20150525141253
browser.startup.homepage: https://www.google.com/
browser.startup.homepage_override.buildID: 20150525141253
browser.startup.homepage_override.mstone: 38.0.5
browser.tabs.closeButtons: 0
browser.tabs.drawInTitlebar: false
browser.tabs.onTop: false
dom.max_chrome_script_run_time: 40
dom.max_script_run_time: 0
dom.mozApps.used: true
extensions.lastAppVersion: 38.0.5
font.internaluseonly.changed: true
gfx.direct2d.disabled: true
gfx.direct3d.last_used_feature_level_idx: 1
layers.acceleration.disabled: true
layers.offmainthreadcomposition.enabled: false
media.gmp-eme-adobe.lastUpdate: 1433177158
media.gmp-eme-adobe.version: 10
media.gmp-gmpopenh264.autoupdate: false
media.gmp-gmpopenh264.enabled: false
media.gmp-gmpopenh264.lastUpdate: 1426092005
media.gmp-gmpopenh264.version: 1.3
media.gmp-manager.buildID: 20150525141253
media.gmp-manager.lastCheck: 1433631874
network.cookie.prefsMigrated: true
network.http.pipelining: true
network.http.proxy.pipelining: true
network.predictor.cleaned-up: true
places.database.lastMaintenance: 1433686248
places.history.expiration.transient_current_max_pages: 92914
plugin.disable_full_page_plugin_for_types: application/pdf
plugin.importedState: true
plugin.state.java: 2
plugin.state.npadobeaamdetect: 0
plugin.state.npctrl: 1
plugin.state.npdeployjava: 0
plugin.state.npfacebookvideocalling: 0
plugin.state.npgeplugin: 1
plugin.state.npgoogletalk: 0
plugin.state.npgoogleupdate: 0
plugin.state.npitunes: 0
plugin.state.npo1d: 0
plugin.state.npunity3d: 1
plugin.state.npvlc: 0
plugin.state.npystate: 0
print.printer_HP_Deskjet_3050_J610_series_(Network).print_bgcolor: false
print.printer_HP_Deskjet_3050_J610_series_(Network).print_bgimages: false
print.printer_HP_Deskjet_3050_J610_series_(Network).print_colorspace:
print.printer_HP_Deskjet_3050_J610_series_(Network).print_command:
print.printer_HP_Deskjet_3050_J610_series_(Network).print_downloadfonts: false
print.printer_HP_Deskjet_3050_J610_series_(Network).print_duplex: 1515870810
print.printer_HP_Deskjet_3050_J610_series_(Network).print_edge_bottom: 0
print.printer_HP_Deskjet_3050_J610_series_(Network).print_edge_left: 0
print.printer_HP_Deskjet_3050_J610_series_(Network).print_edge_right: 0
print.printer_HP_Deskjet_3050_J610_series_(Network).print_edge_top: 0
print.printer_HP_Deskjet_3050_J610_series_(Network).print_evenpages: true
print.printer_HP_Deskjet_3050_J610_series_(Network).print_footercenter:
print.printer_HP_Deskjet_3050_J610_series_(Network).print_footerleft: &PT
print.printer_HP_Deskjet_3050_J610_series_(Network).print_footerright: &D
print.printer_HP_Deskjet_3050_J610_series_(Network).print_headercenter:
print.printer_HP_Deskjet_3050_J610_series_(Network).print_headerleft: &T
print.printer_HP_Deskjet_3050_J610_series_(Network).print_headerright: &U
print.printer_HP_Deskjet_3050_J610_series_(Network).print_in_color: true
print.printer_HP_Deskjet_3050_J610_series_(Network).print_margin_bottom: 0.5
print.printer_HP_Deskjet_3050_J610_series_(Network).print_margin_left: 0.5
print.printer_HP_Deskjet_3050_J610_series_(Network).print_margin_right: 0.5
print.printer_HP_Deskjet_3050_J610_series_(Network).print_margin_top: 0.5
print.printer_HP_Deskjet_3050_J610_series_(Network).print_oddpages: true
print.printer_HP_Deskjet_3050_J610_series_(Network).print_orientation: 0
print.printer_HP_Deskjet_3050_J610_series_(Network).print_page_delay: 50
print.printer_HP_Deskjet_3050_J610_series_(Network).print_paper_data: 1
print.printer_HP_Deskjet_3050_J610_series_(Network).print_paper_height: 11.00
print.printer_HP_Deskjet_3050_J610_series_(Network).print_paper_name:
print.printer_HP_Deskjet_3050_J610_series_(Network).print_paper_size_type: 0
print.printer_HP_Deskjet_3050_J610_series_(Network).print_paper_size_unit: 0
print.printer_HP_Deskjet_3050_J610_series_(Network).print_paper_width: 8.50
print.printer_HP_Deskjet_3050_J610_series_(Network).print_plex_name:
print.printer_HP_Deskjet_3050_J610_series_(Network).print_resolution: 1515870810
print.printer_HP_Deskjet_3050_J610_series_(Network).print_resolution_name:
print.printer_HP_Deskjet_3050_J610_series_(Network).print_reversed: false
print.printer_HP_Deskjet_3050_J610_series_(Network).print_scaling: 1.00
print.printer_HP_Deskjet_3050_J610_series_(Network).print_shrink_to_fit: true
print.printer_HP_Deskjet_3050_J610_series_(Network).print_to_file: false
print.printer_HP_Deskjet_3050_J610_series_(Network).print_unwriteable_margin_bottom: 0
print.printer_HP_Deskjet_3050_J610_series_(Network).print_unwriteable_margin_left: 0
print.printer_HP_Deskjet_3050_J610_series_(Network).print_unwriteable_margin_right: 0
print.printer_HP_Deskjet_3050_J610_series_(Network).print_unwriteable_margin_top: 0
privacy.cpd.cookies: false
privacy.cpd.downloads: false
privacy.cpd.formdata: false
privacy.cpd.history: false
privacy.cpd.sessions: false
privacy.popups.showBrowserMessage: false
privacy.sanitize.migrateFx3Prefs: true
privacy.sanitize.timeSpan: 0
storage.vacuum.last.index: 1
storage.vacuum.last.places.sqlite: 1432774225

Important Locked Preferences
----------------------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0

Library Versions
----------------

NSPR
Expected minimum version: 4.10.8
Version in use: 4.10.8

NSS
Expected minimum version: 3.18.1 Basic ECC
Version in use: 3.18.1 Basic ECC

NSSSMIME
Expected minimum version: 3.18.1 Basic ECC
Version in use: 3.18.1 Basic ECC

NSSSSL
Expected minimum version: 3.18.1 Basic ECC
Version in use: 3.18.1 Basic ECC

NSSUTIL
Expected minimum version: 3.18.1
Version in use: 3.18.1

Experimental Features
---------------------

Comment 3

[neopeeves]

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)

Comment 4

[Marco Bonardo [:mak]]

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.

Comment 5

[neopeeves]

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

Comment 6

[:Gijs (he/him)]

(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?

Comment 7

[neopeeves]

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.

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

Is there a lot/some WebGL usage involved?

Comment 9

[neopeeves]

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.

Comment 10

[Milan Sreckovic [:milan] (needinfo for best results)]

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

Comment 11

[Milan Sreckovic [:milan] (needinfo for best results)]

Looking at the stack, this is probably relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=1116812#c111

Comment 12

[Milan Sreckovic [:milan] (needinfo for best results)]

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?

Comment 13

[(Away)]

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)

Comment 14

[neopeeves]

Attachment: memory-report.json.gz

1,150,000K memory about:memory log

Comment 15

[neopeeves]

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.

Comment 16

[Nicolas Silva [:nical]]

(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).

Comment 17

[Ton [:Tonnes]]

My few cents:
   
For starters, you’re using the latest Intel 8.15.10.2869 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.

Comment 18

[Emanuel Hoogeveen [:ehoogeveen]]

The problem with integrated GPUs without any dedicated VRAM is, as I understand it, that they have to *share* the virtual address space with the process they run in. That means buggy drivers that don't do a very good job of cleaning up after themselves can put Firefox in a difficult situation. The more fragmented the address space gets, the harder it gets to allocate large chunks of memory like the ones needed for painting, and so you start seeing issues like this (where Firefox doesn't crash altogether but it fails to paint correctly).

As for why Firefox can't release all memory after you close all but one tab, there's various reasons for this. Memory in Firefox is allocated in aligned, 1MB chunks. Smaller regions are then allocated from these chunks, which allows for fast allocation without talking to the OS. However, if even a single byte of a chunk remains in use, it cannot be deallocated, keeping the whole MB allocated (but mostly decommitted, so it's only a problem in terms of virtual memory).

Various data structures in Firefox are shared, so they end up tracking the same data across many websites (possibly saving memory when multiple sites use the same data). When you close a tab, some of the data in these structures is no longer needed, but that doesn't mean we can just throw the whole thing away - other pages may be using data further down in the shared list. So this is another source of fragmentation, and this memory can *not* be decommitted.

And of course there's leaks. Firefox can leak (though we try hard to fix any leaks that are found), but extensions can also leak and so can binary plugins. All of this can hold small or large amounts of memory alive all over the place, and end up keeping a large number of chunks alive even though they are mostly empty.

These are all sources of memory fragmentation, though everything except memory leaks can, in principle, be compacted. We actually do this for memory allocated by the JavaScript engine's garbage collector: if you go idle for a while, or if we get a 'memory pressure' event, we do a 'shrinking GC' that packs the GC memory as tightly as possible to leave no holes.

But most of Firefox is written in C++, which does not come with such a mechanism built into the language. To move data around, you have to update all variables that point directly to that data, which means you have to know about all the pointers. This is exactly what the JavaScript engine's garbage collector does: it knows about every pointer and updates them during GC. But doing this for all of Firefox would be essentially impossible - we're talking millions of lines of code, some dating back to the late '90s. And that's not even considering the layer of abstraction required to make it all work.

Comment 19

[neopeeves]

Attachment: Memory report taken WHILE visual glitches were happening

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.

Comment 20

[(Away)]

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 [578]

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?)

Comment 21

[neopeeves]

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.

Comment 22

[Nicholas Nethercote [inactive]]

> 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.

Comment 23

[neopeeves]

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.

Comment 24

[info]

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

Comment 25

[alex_mayorga]

¡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!

Comment 26

[neopeeves]

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

Comment 27

[neopeeves]

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

Comment 28

[:Gijs (he/him)]

(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.

Comment 29

[Emanuel Hoogeveen [:ehoogeveen]]

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.

Comment 30

[neopeeves]

Not fixed. Just encountered it again with FF44.0.2 and fully updated plugins when firefox got up to 1,200,000K memory

Comment 31

[neopeeves]

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