dE Reporter
	Description • 9 years ago

I've never seen a FF without infinite hunger for memory. Prominently, overtime, it keeps on increasing and never reduces even if you do a GC and CC or 'Minimize memory usage' in about:memory.

It doesn't matter if add ons are disabled or not and whether FF is running in safe mode or not. With addons enabled, the memory usage will simply increase, but the the memory leak like behavior will will persist. So if in safe mode, the memory usage increases to 500M after X amount of activities, with addons enabled, it'll reach 800M. This is with all tabs closed.

Furthermore, in about:memory, there's a mismatch in the amount of memory reported to be used vs Linux's residential memory usage (excluding shared, if you include that it'll get worst).

$ ps -ww -Ao 'rss,vsz,args' | grep firefox
817748 2252756 /opt/firefox/firefox

So, as per ps, it reports to be 817748 KB here.

At the same time, I created GC and CC logs along with the memory reports which I've uploaded.

	dE Reporter
	Comment 1 • 9 years ago

CC log

http://1drv.ms/1i5PiET

gc log

http://1drv.ms/1i5PpQL

	Nicholas Nethercote [inactive]
	Comment 2 • 8 years ago

From the attached memory reports, this is suspicious:

> ├──191.62 MB (27.89%) -- window-objects
> │  ├──133.18 MB (19.39%) -- top(none)/detached
> │  │  ├──131.18 MB (19.09%) -- window(chrome://browser/content/browser.xul)
> │  │  │  ├──101.75 MB (14.81%) -- js-compartment([System Principal], about:blank)
> │  │  │  │  ├───64.88 MB (09.44%) -- classes
> │  │  │  │  │   ├──23.20 MB (03.38%) -- class(Function)
> │  │  │  │  │   │  ├──21.46 MB (03.12%) -- objects
> │  │  │  │  │   │  │  ├──21.12 MB (03.07%) ── gc-heap [34]
> │  │  │  │  │   │  │  └───0.34 MB (00.05%) ── malloc-heap/slots [34]
> │  │  │  │  │   │  └───1.74 MB (00.25%) ++ shapes

34 detached windows, which suggests some kind of window leak.

When these memory reports were taken, it looks like the following add-ons were enabled:

- mozilla-firetray
- Video DownloadHelper
- IP Address and Domain Information
- Web of Trust
- Session Manager
- cliget

(I had to lookup the hex ids to identify these, so may have made some mistakes.)

Comment 0 says that add-ons do make things worse.

Experience has shown this kind of leak is most commonly caused by add-ons.

dE, it would be very helpful if you could try selectively disabling your add-ons and see if you still get large amounts of memory in the "top(none)/detached" sub-tree in about:memory.

Apart from that, 500 MiB of memory usage isn't unusual. It depends entirely on the sites visited.

	Nicholas Nethercote [inactive]
	Comment 3 • 8 years ago

Needinfo'ing dE as per comment 2.

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

We can reopen this if dE gets back with more info.

	dE Reporter
	Comment 5 • 8 years ago

Ok, I'm disabling all addons and trying it out again.

	dE Reporter
	Comment 7 • 8 years ago

The latest attachment is without using any addons.

	dE Reporter
	Comment 8 • 8 years ago

The browser started at 162960 and after closing all tabs and additional windows, it was 281444 (after GC/CC and minimize memory usage).

	:Gijs (he/him)
	Comment 9 • 8 years ago

(In reply to Nicholas Nethercote [:njn] from comment #3)
> Needinfo'ing dE as per comment 2.

:njn, given the memory report, is there more that can be done here now?

Putting this back in untriaged so it ends up somewhere sensible once we have a cause, rather than Fx::General 'by default'.

	Nicholas Nethercote [inactive]
	Comment 10 • 8 years ago

Looking at the new memory reports, with addons disabled.

> 392.95 MB (100.0%) -- explicit
> ├──259.74 MB (66.10%) ── heap-unclassified

392 MB "explicit" is not at all unusual. The detached windows appear to be gone, which indicates that one of the addons is likely at fault.

But 66% "heap-unclassified" *is* unusual. The way to understand that is to use DMD, the instructions for which are here: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/DMD.

dE, how adventurous are you feeling? DMD isn't part of normal Firefox builds, so you'll need a special build. Either you could do this yourself, or I could create one for you via try server. Then you'd need to follow the instructions on triggering and processing the output, and put the results up in this bug. It's a moderately difficult exercise for a newcomer, and if it's more than you're willing to try I understand.

	dE Reporter
	Comment 11 • 8 years ago

I use Gentoo. I'll do it.

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

dE, did you have any luck with DMD? Nick can you provide a DMD build if necessary?

	Nicholas Nethercote [inactive]
	Comment 13 • 8 years ago

I can provide one if necessary. dE, let me know if you need one.

	dE Reporter
	Comment 14 • 8 years ago

I just need to pass --enable-dmd to the configure script right?

	Nicholas Nethercote [inactive]
	Comment 15 • 8 years ago

DMD docs are here: https://developer.mozilla.org/en-US/docs/Mozilla/Performance/DMD

	Michelle Funches - QA
	Comment 16 • 8 years ago

@Reporter: has the information provided here in helped resolve the issue?

	dE Reporter
	Comment 17 • 8 years ago

Yes, I've build FF with DMD.

I'll be using that build Sunday the whole day, so I'll report.

	dE Reporter
	Comment 18 • 8 years ago

As per the instructs I need to run FF with

mach run --dmd; use --mode

To enable DMD.

But there's no mach, use command on my system nor in the FF build directory

	dE Reporter
	Comment 19 • 8 years ago

From the FF DMD build.

	dE Reporter
	Comment 20 • 8 years ago

From the FF dmd build

	dE Reporter
	Comment 21 • 8 years ago

From the FF dmd build

	dE Reporter
	Comment 22 • 8 years ago

From the FF dmd build

	dE Reporter
	Comment 23 • 8 years ago

From the FF dmd build

	Nicholas Nethercote [inactive]
	Comment 24 • 8 years ago

Thank you for the data files. For DMD, you'll need to run the dmd.py script on the output, as described at https://developer.mozilla.org/en-US/docs/Mozilla/Performance/DMD#Processing_the_output_2. You'll invoke it omething like this:

  $OBJDIR/dist/bin/dmd.py -f 10 dmd.json.gz > dmd.txt

and then attach dmd.txt to the bug.

This step is necessary because the dmd.json.gz file alone doesn't have enough info for the stack traces to be useful. dmd.py will combine the information in dmd.json.gz with information from the binary to give more useful stack traces.

Thank you.

	Michelle Funches - QA
	Comment 25 • 8 years ago

Resolving as incomplete: DE, if the issue can be reproduced on a current build please provide the dmd.txt as requested in Comment 24.