Henry Noble Reporter
	Description • 7 years ago

User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:49.0) Gecko/20100101 Firefox/49.0 SeaMonkey/2.46
Build ID: 20161213183751

Steps to reproduce:

Running Firefox 51 (64bit) with seven tabs on Windows 10 (general release build 14393, not Insider Preview).  Same home page tab group every time Firefox is started.  The issue may have existed before version 51, but has now become so annoying I'm filing this report.


Actual results:

Over the course of several hours, Firefox consumes more and more memory, eventually becoming so sluggish and unresponsive I have to close it and restart.  I have 16 Gb of RAM on this i7 system, so Firefox may grab 5 Gb (or more) of RAM  before I close and restart.  Closing Firefox releases the memory and then the cycle begins again.  Other programs do not appear to be adversely affected by the slowdown of Firefox.


Expected results:

I would expect relatively constant memory usage because the seven tabs opened at startup are all that are opened.  My guess is that something in the refresh of pages (news sites, weather, etc.) is failing to discard old data.

	Andre Klapper
	Comment 1 • 7 years ago

Please enter the address "about:memory?verbose" (with a lower-case "v") in the address bar and attach (using the "Add an attachment" link above) the output here.

Do you have any add-ons? It could be useful to test without add-ons.

	Henry Noble Reporter
	Comment 2 • 7 years ago

When I run the address "about:memory?verbose", I do not get diagnostic information.  Instead, there are four main choices:  Show memory reports, Save memory reports, Free memory, Save GC &CC logs.
  
Measure and save produces a json.gz file.  Is that what you want?

Something new.  While Firefox was operating sluggishly, I clicked on Save GC & CC logs.  It took several minutes to produce two large files:  cc-edges is about 6.5 Mb, and gc-edges is about 9.3 Mb.  After creating those files, Firefox's memory consumption dropped by 6 Gb and Firefox again responded normally.

When I closed and restarted Firefox, an additional 3.3 Gb of memory was released.  Total released:  9.3 Gb.

	Henry Noble Reporter
	Comment 3 • 7 years ago

Add-ons installed and running are Adblock Plus, HTTPS-Everywhere, NoScript, and WOT.

	Henry Noble Reporter
	Comment 4 • 7 years ago

File requested by Andre Klapper.

	Henry Noble Reporter
	Comment 5 • 7 years ago

Two Task Manager snapshots to illustrate the magnitude of the memory shrinkage problem.

Once closed and restarted, Firefox functions normally, but again begins the slow process of consuming memory.

	u554753
	Comment 6 • 7 years ago

Hi Henry,

Can you also provide us with a Cleopatra profile? You can follow the instructions on this link: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/Cleopatra and share the URL in a comment below.

We can also use this data to monitor what exactly might be the cause of the sluggish behavior.

	Eric Rahm [:erahm]
	Comment 7 • 7 years ago

Interesting snippets:

> │  ├──2,821.30 MB (39.14%) -- top(http://www.realclearpolitics.com/, id=19)
> │  │  ├──1,614.34 MB (22.40%) -- active
> │  │  │  ├──1,601.75 MB (22.22%) -- window(http://www.realclearpolitics.com/)
> │  │  │  │  ├────913.65 MB (12.68%) ++ js-compartment(http://www.realclearpolitics.com/)
> │  │  │  │  ├────345.47 MB (04.79%) -- dom
> │  │  │  │  │    ├──275.67 MB (03.82%) ── element-nodes [140]
> │  │  │  │  │    └───69.79 MB (00.97%) -- (5 tiny)
> │  │  │  │  │        ├──57.57 MB (00.80%) ── text-nodes [139]
> │  │  │  │  │        ├───6.14 MB (00.09%) ── other [145]
> │  │  │  │  │        ├───3.35 MB (00.05%) ── comment-nodes [137]
> │  │  │  │  │        ├───1.86 MB (00.03%) ── orphan-nodes [137]
> │  │  │  │  │        └───0.87 MB (00.01%) ── event-targets [141]
> │  │  │  │  ├────339.00 MB (04.70%) ── style-sheets [140]
> │  │  │  │  └──────3.64 MB (00.05%) ++ (3 tiny)
> │  │  │  └─────12.59 MB (00.17%) ++ (6 tiny)
> │  │  └──1,206.96 MB (16.75%) ++ js-zone(0x1fcb31ce000)
> ...
> 319,982 (100.0%) -- event-counts
> └──319,982 (100.0%) -- window-objects
>    ├──154,052 (48.14%) -- top(http://www.realclearpolitics.com/, id=19)/active
>    │  ├──153,474 (47.96%) -- window(http://www.realclearpolitics.com/)/dom
>    │  │  ├──151,954 (47.49%) ── event-listeners [138]
>    │  │  └────1,520 (00.48%) ── event-targets [141]
>    │  └──────578 (00.18%) ++ (6 tiny)
> ...
> 1,576 (100.0%) -- js-main-runtime-compartments
> ├──1,214 (77.03%) -- user
> │  ├────378 (23.98%) ++ (325 tiny)
> │  ├────140 (08.88%) ── [Expanded Principal [http://www.realclearpolitics.com/]] [140]
> │  ├────140 (08.88%) ── [Expanded Principal [http://www.realclearworld.com/]] [140]
> │  ├────140 (08.88%) ── http://www.realclearpolitics.com/, about:blank [140]
> │  ├────140 (08.88%) ── http://www.realclearworld.com/, about:blank [140]
> │  ├────138 (08.76%) ── http://www.realclearpolitics.com/ [138]
> │  └────138 (08.76%) ── http://www.realclearworld.com/ [138]

So something is injecting/leaking a ton of compartments, most likely due to registering an event listener and not cleaning it up. I would guess this is add-on related, given your list I'd suggest:

#1 - Remove WOT (if that's Web of Trust), it has been delisted for violating our privacy policy
#2 - Try disabling Adblock Plus, that's caused high memory usage in the past

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

There's some leak that we added in 51 and got fixed in 52 that hits AdblockPlus, so you could try out beta 52, or disabling ABP and see if it helps.

	Henry Noble Reporter
	Comment 9 • 7 years ago

I have been running ver. 52.0 (64 bit) for a day now, and the reported problem has either vanished or is so small as to be invisible.

There is one small side issue, which seems no longer relevant, but I will mention for the sake of completeness.  The memory leak problem was more rapid when I had a VMWare virtual machine running alongside Firefox.  I was not able to quantify the effect of VMWare, but maybe this mention will give you another clue as to what was happening.  I now have had VMWare running with Firefox 52.0 for several hours, and it seems stable with and without VMWare.

Thanks to all who worked on this issue.

From my perspective as an end-user, the problem is solved and the report may be closed.

	Eric Rahm [:erahm]
	Comment 10 • 7 years ago

(In reply to Henry Noble from comment #9)
> I have been running ver. 52.0 (64 bit) for a day now, and the reported
> problem has either vanished or is so small as to be invisible.
> 
> There is one small side issue, which seems no longer relevant, but I will
> mention for the sake of completeness.  The memory leak problem was more
> rapid when I had a VMWare virtual machine running alongside Firefox.  I was
> not able to quantify the effect of VMWare, but maybe this mention will give
> you another clue as to what was happening.  I now have had VMWare running
> with Firefox 52.0 for several hours, and it seems stable with and without
> VMWare.
> 
> Thanks to all who worked on this issue.
> 
> From my perspective as an end-user, the problem is solved and the report may
> be closed.

Great to hear! I'll close this for now, but if you start to see the issue again please feel free to reopen.