Michael S Reporter
	Description • 10 years ago

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 (Beta/Release)
Build ID: 20131205075310

Steps to reproduce:

FF 26 on Windows 7 Ult x64 & Windows 8 x64

The memory usage of Firefox is consistently at or above ~800MB, typically residing around 1GB.

I can only assume that it is due to an extension or combination of extensions that I use. Cork from #firefox suggested I create a bug so the memshrink team could take a look.

	therube
	Comment 1 • 10 years ago

See if anything noted, or similar, in my Bug relates to you:

Bug 966662 - Memory usage increase with Firefox 26 compared to earlier

You really need to provide more information on your circumstances.

Also check to see if dropping back to FF 25 makes a difference.

	Dane MacMillan [:danemacmillan]
	Comment 2 • 10 years ago

I'm on OSX Mavericks, late 2013 Mac Pro Retina model, using Nightly, version 30.

For a while now I've noticed that memory usage for Firefox is abnormally high, averaging around 1.20GB after about an hour of usage, even if using a moderate number of tabs. Typically, after just a few minutes of browsing, memory jumps to around 700-800MB like the OP.

Here's a photo to illustrate:

http://i.imgur.com/68ViDgA.png

What else would make debugging this easier? A dump of memory:about?

I want to blame it on just being a Nightly, experimental build, but I can't see why it would be so consistent. It really quite noticeable.

	Florian Bender
	Comment 3 • 10 years ago

Did you try safe mode and see if the problem persists?

	Michael S Reporter
	Comment 4 • 10 years ago

With 5 app-tabs and 3 normal tabs FF sits at ~530MB usage after they all load. It still seems pretty high to me.

	ovidiu boca[:Ovidiu]
	Comment 5 • 9 years ago

Hi, 
I have tested this on Win 7 64x with FF Nightly 45.0a1 (2015-11-09) and I didn't see any problems. 
Please download the latest Nightly version from here: https://nightly.mozilla.org/ and see if the problems can be reproduced.

	ovidiu boca[:Ovidiu]
	Comment 6 • 9 years ago

Hi, 

First of all please download the latest Nightly version from here: https://nightly.mozilla.org/ and see if the problems can be reproduced.
If you have the problem, please provide a memory report as an attachment to this bug. Please go to this link for more details:

https://developer.mozilla.org/en-US/docs/Mozilla/Performance/about:memory

	Nicholas Nethercote [inactive]
	Comment 7 • 8 years ago

Hi, Michael S. Can you please collect memory reports again once memory usage gets high? Sorry for asking again, but the measurements in about:memory have changed a lot in the past two years, so looking at old reports is probably not that useful.

Also, can you please list any extensions you have enabled? They can greatly affect memory usage. Go to about:support and click on the "Copy text to clipboard" button. Thank you.

Dane, if you still have problems can you please file a new, separate bug, with updated measurements, and put "[MemShrink]" in the whiteboard field? It's confusing to have multiple people commenting on a "high memory usage" bug because the root causes may be entirely different. Experience has shown that better results occur when each person having problems files a separate bug. Thank you.

	Michael S Reporter
	Comment 8 • 8 years ago

Sorry about the delay. Memory usage has seem to have gotten better, it does still seem a bit high, but more in-check.

I have attached an updated memory report (FF has been open ~6 hours at this point).

I have also attached the output of about:support.

	Nicholas Nethercote [inactive]
	Comment 11 • 8 years ago

Thank you for the extra info.

This is suspicious:

> │  ├───65.93 MB (06.84%) -- top(none)
> │  │   ├──65.93 MB (06.84%) -- detached
> │  │   │  ├──32.77 MB (03.40%) ++ (23 tiny)
> │  │   │  ├──22.89 MB (02.37%) -- window(chrome://browser/content/browser.xul)
> │  │   │  │  ├──15.93 MB (01.65%) ++ js-compartment([System Principal], about:blank)
> │  │   │  │  └───6.96 MB (00.72%) ++ (3 tiny)
> │  │   │  └──10.27 MB (01.06%) ++ window(chrome://mozapps/content/downloads/unknownContentType.xul)
> │  │   └───0.00 MB (00.00%) ── ghost/window(<anonymized-861>)/dom/other
> 
> 1 (100.0%) -- ghost-windows
> └──1 (100.0%) ── <anonymized-861>

Ghost windows and/or detached windows usually indicate leaks, and they're often caused by extensions. And you have 15 extensions enabled, which is a high number.

Unfortunately, the only way forward here is to selectively disable extensions in order to identify which ones are the cause. Firebug has been known to cause problems in the past, so that might be a good one to start with.

	Andrew McCreight [:mccr8]
	Comment 12 • 8 years ago

The ghost-windows memory usage is so tiny I wouldn't worry too much about it.

browser.xul detached windows like that are a sign of leaking a browser window, in my experience. Particularly since the count is 9, which isn't too high. You can see the count by looking under js-compartment([System Principal], about:blank), and there will be entries like this:

│  │   │  │  │  ├───1.13 MB (00.12%) ── cross-compartment-wrapper-table [9]
│  │   │  │  │  ├───0.39 MB (00.04%) ── compartment-tables [9]
│  │   │  │  │  ├───0.20 MB (00.02%) ── type-inference/object-type-tables [9]
│  │   │  │  │  └───0.04 MB (00.00%) ── sundries/malloc-heap [9]

The [9] indicates that there are 9 of them.

So, you can try opening and closing a window in the browser and see if that count goes up. If it does, then you have some steps to reproduce, and you can try disabling addons and repeating it until you figure out which addon is doing it. As Nick said, it could really be any addon, which might keep around a strong reference to a window.

	Eric Rahm [:erahm]
	Comment 13 • 8 years ago

Michael S, can you try out what Andrew suggests in comment 12?

	Michael S Reporter
	Comment 14 • 8 years ago

I will gladly look at this.

I have disabled Firebug already and looking in about:memory I can't (at least with FF's find) any entry for "js-compartment([System Principal], about:blank)" anywhere. The only js-compartment entries I can find are related directly to a specific page.

I'm not sure if this is my doing something incorrectly (or looking improperly), but I'll keep an eye on it and see if I can figure this out. Any other input/suggestions on this is always welcome.

Thanks!

	Andrew McCreight [:mccr8]
	Comment 15 • 8 years ago

The first thing you want to look out for is anything under top(none)/detached/window(chrome://browser/content/browser.xul), like in comment 11. If you do see that, then you'll have to expand out the subtrees to find the js-compartment stuff, or check the verbose box when you measure in about:memory.