Wolfgang Rosenauer [:wolfiR] Reporter
	Description • 12 years ago

Since I've upgraded to Aurora 18 I see every other day a big increase in memory consumption.

about:memory shows it in heap-unclassified
7,279,976,448 B (100.0%) -- rss
├──7,094,112,256 B (97.45%) -- anonymous
│  ├──7,092,715,520 B (97.43%) ── anonymous, outside brk() [rw-p] [6191]
│  └──────1,396,736 B (00.02%) ── anonymous, outside brk() [rwxp] [15]

I couldn't verify in safe-mode yet because I cannot trigger the behaviour. It just starts at some point w/o me knowing why.

I understand there is quite some data missing to debug this further so please let me know what's needed for debugging that issue.

	Wolfgang Rosenauer [:wolfiR] Reporter
	Comment 1 • 12 years ago

CPU usage also goes high if the memory is growing.
Currently have around 900MB in heap-unclassified and around 150% cpu usage in "top" on my quad-core cpu.

	Nicholas Nethercote [inactive]
	Comment 2 • 12 years ago

7 GiB of RSS is definitely excessive.  Can you copy and paste the full contents of about:memory?verbose into a file and attach that to this bug?  Also, do you have any add-ons enabled?

	Wolfgang Rosenauer [:wolfiR] Reporter
	Comment 3 • 12 years ago

I have some addons:

About startup 0.1.10 true aboutstartup@glandium.org 
about:telemetry 0.14 true ping.telemetry@mozilla.com
Adblock Plus 2.1.2 true {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Firebug 1.10.6 true firebug@software.joehewitt.com
openSUSE Firefox Erweiterungen 1.0.2 true susefox@opensuse.org
PrivacyChoice TrackerBlock 2.2 true trackerblock@privacychoice.org

	Nicholas Nethercote [inactive]
	Comment 4 • 12 years ago

├──7,141,589,871 B (93.84%) ── heap-unclassified

Wow.  That's extreme.  We have tools for gaining insight into "heap-unclassified" memory, but to dig further I'll need steps to reproduce the problem.

Would you be able to try selectively disabling your add-ons, to see if you can pin down the problem to one of them?  I'd suggest starting with PrivacyChoice, because I've not heard of that before and one of the reviews on its AMO page says: "Found this addon to be the culprit of massive performance problems with Firefox, slowing Firefox startup a LOT, causing freezing every time loading Twitter and generally slowing browsing down."

	Mike Hommey [:glandium]
	Comment 5 • 12 years ago

As mentioned on irc by karlt, this could be bug 770692.

	Nicholas Nethercote [inactive]
	Comment 6 • 12 years ago

> this could be bug 770692.

Wrong bug number?

	Mike Hommey [:glandium]
	Comment 7 • 12 years ago

(In reply to Nicholas Nethercote [:njn] from comment #6)
> > this could be bug 770692.
> 
> Wrong bug number?

Indeed. bug 770612

	Jonathan Protzenko [:protz]
	Comment 8 • 12 years ago

Just in case this is useful, I'm experiencing the same bug, so here's my about:memory. Firefox isn't eating all my memory yet but over the last few days it's been going near 97% of my 4GB.

My addons:
Adblock Plus2.1.2true{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}
Browse By Name1.1truejid0-BJHK9jcBnvyTwamzSSjJvyQXmOE@jetpack
Dictionnaire français «Classique»4.3truefr-classique@dictionaries.addons.mozilla.org
DOM Inspector2.0.13trueinspector@mozilla.org
Enter Selects7trueenter.selects@agadak.net
Lazarus: Form Recovery2.3truelazarus@interclue.com
pwgen - Password Generator0.5truepwgen@alouche.net
Readability2.4truereadability@readability.com
Suspend background tabs1.0.1truesuspendbackgroundtabs@adblockplus.org

	Nicholas Nethercote [inactive]
	Comment 9 • 12 years ago

> Just in case this is useful, I'm experiencing the same bug

Are you on Linux as well?

	Nicholas Nethercote [inactive]
	Comment 10 • 12 years ago

Wolfgang, Jonathan:  you could test if this is the same as bug 770612 by disabling transparent huge pages.  Do that with the following:

  echo never > /sys/kernel/mm/transparent_hugepage/enabled

You might want to save a copy of the file before doing that, so you can revert to the previous behaviour once you've finished testing.

	Jonathan Protzenko [:protz]
	Comment 11 • 12 years ago

Yes I am on Linux (x86-64). I've restarted Firefox but next time it eats all the memory in my system, I'll make sure I try disabling transparent huge pages.

	Nicholas Nethercote [inactive]
	Comment 12 • 12 years ago

I'm not certain if disabling it once the problem occurs will work.  You might have to disable it beforehand, and then if the problem doesn't reappear after a while, that's evidence that it's the transparent huge pages that are the cause.

	Wolfgang Rosenauer [:wolfiR] Reporter
	Comment 13 • 12 years ago

(In reply to Nicholas Nethercote [:njn] from comment #4)
> 
> Would you be able to try selectively disabling your add-ons, to see if you
> can pin down the problem to one of them?  I'd suggest starting with
> PrivacyChoice, because I've not heard of that before and one of the reviews
> on its AMO page says: "Found this addon to be the culprit of massive
> performance problems with Firefox, slowing Firefox startup a LOT, causing
> freezing every time loading Twitter and generally slowing browsing down."

Did that. But no real change. Still had quite some heap-unclassified after a few hours of usage.
Haven't seen the 8GB issue but this didn't happen daily anyway.

(In reply to Nicholas Nethercote [:njn] from comment #10)
> Wolfgang, Jonathan:  you could test if this is the same as bug 770612 by
> disabling transparent huge pages.  Do that with the following:
> 
>   echo never > /sys/kernel/mm/transparent_hugepage/enabled
> 
> You might want to save a copy of the file before doing that, so you can
> revert to the previous behaviour once you've finished testing.

Set it to "never" here but after some hours I'm already at 1GB again.

	Wolfgang Rosenauer [:wolfiR] Reporter
	Comment 14 • 12 years ago

(In reply to Wolfgang Rosenauer [:wolfiR] from comment #13)
> Did that. But no real change. Still had quite some heap-unclassified after a
> few hours of usage.
> Haven't seen the 8GB issue but this didn't happen daily anyway.

Sorry, I didn't do it for all addons yet since it basically takes one day to verify for one of them. It wasn't PrivacyChoice though.

	Nicholas Nethercote [inactive]
	Comment 15 • 12 years ago

To recap:  Wolfgang, Jonathan and Stephan (from bug 812704) have all seen this recently.  This is scary.

I run Ubuntu Linux 12.04 myself and have never seen anything like this;  heap-unclassified is typically 8--12% for me.  So it's presumably due to a Linux config issue, a Firefox config issue, or a workload issue.  Concrete steps to reproduce would be hugely helpful, though I understand getting them might be difficult.

	Nicholas Nethercote [inactive]
	Comment 16 • 12 years ago

It looks like something bad happened in the latest Aurora update. 

Wolfgang said "Since I've upgraded to Aurora 18 I see every other day a big increase in memory consumption."

Stephan said "Since its last update, my Aurora-channel Firefox has been leaking like crazy (version 18.0a2 (2012-11-14))."

	Stephan Sokolow
	Comment 17 • 12 years ago

(In reply to Nicholas Nethercote [:njn] from comment #15)
> I run Ubuntu Linux 12.04 myself and have never seen anything like this; 
> heap-unclassified is typically 8--12% for me.  So it's presumably due to a
> Linux config issue, a Firefox config issue, or a workload issue.  Concrete
> steps to reproduce would be hugely helpful, though I understand getting them
> might be difficult.

Definitely difficult. I'm running Lubuntu 12.04 (so no kernel config difference) and, while I was trying to make time to test with THP disabled, the 8GiB resident size shrunk down to 1.5GiB (well within normal range) over the course of 12 or so hours.

I can't think of anything distinctive that I was doing during those time periods. I was torrenting some Humble Bundle purchases both times, but I'm still torrenting things and torrenting doesn't seem to be a trigger in itself. I was burning DVDs full of Windows ports of libre games like OpenTTD and Rigs of Rods for Christmas gifts, but the first time happened before I did that.

(In reply to Nicholas Nethercote [:njn] from comment #16)
> It looks like something bad happened in the latest Aurora update. 
> 
> Wolfgang said "Since I've upgraded to Aurora 18 I see every other day a big
> increase in memory consumption."
> 
> Stephan said "Since its last update, my Aurora-channel Firefox has been
> leaking like crazy (version 18.0a2 (2012-11-14))."

Keep in mind that I'm not 100% certain it's only that specific version. I leave Firefox running for up to a week at a time and don't always notice (or ignore) requests to download updates or to restart so it's possible I skipped a build or two entirely.

	Jonathan Protzenko [:protz]
	Comment 18 • 12 years ago

I'm trying to figure out STR but it's hard. In the meanwhile, I noticed that the Firefox CPU usage grew up (around 150%) when experiencing the bug, so I kill -SIGSEGV'd Firefox to trigger the crash reporter, in the unlikely event that there's something useful on the stack.

486e0d55-f0f5-ebc7-3a6b51b6-2a3345a1

	Mike Hommey [:glandium]
	Comment 19 • 12 years ago

Are you all using mozilla.org builds or builds from distro? If the latter, can you attach the output for objdump -T /wherever/the/firefox/binary/is/firefox ?

	Jonathan Protzenko [:protz]
	Comment 20 • 12 years ago

mozilla.org builds (aurora)

	Stephan Sokolow
	Comment 22 • 12 years ago

64-bit mozilla.org build since at least one update before this problem started cropping up.

	Wolfgang Rosenauer [:wolfiR] Reporter
	Comment 23 • 12 years ago

I'm using my own build. That is currently from 2012-11-04.

	Justin Lebar (not reading bugmail)
	Comment 24 • 12 years ago

FWIW I see a big spike in memory usage on Windows Aurora builds starting around 11/9.  I think Telemetry is filtering out basically all of our Linux data due to insufficient sample sizes, so I can't say anything for Linux.

Memory usage may be decreasing in the latest Aurora builds.  Or it may just take a few days for us to see the high memory usage.

	Wolfgang Rosenauer [:wolfiR] Reporter
	Comment 25 • 12 years ago

I did further testing with disabling addons and to me it seems that my case is fixed with disabling firebug. I usually was able to reproduce quite some memory footprint within some hours of usage. Now after almost a full working day running with firebug disabled I only see around 90MB heap-unclassified.

Please note that I didn't use Firebug in most cases. It was just installed because I need to from time to time. Version is 1.10.6 fwiw.
I'll will still watch it but wanted to let you know since I'm pretty sure about it.

	Stephan Sokolow
	Comment 26 • 12 years ago

That'd make sense as a cause.

I also have Firebug installed because, despite it being notably heavier than the built-in developer tools, I just can't stand how the thin border at the top of the Markup Panel makes it feel like it's floating over the content window rather than pushing it out of the way.

	Jonathan Protzenko [:protz]
	Comment 27 • 12 years ago

I don't have Firebug installed. I'm on holidays right now so I can't bisect my set of addons :-/.

	Nicholas Nethercote [inactive]
	Comment 28 • 12 years ago

I just installed Firebug 1.10.6 on my Linux64 day-to-day browser instance.  I'll watch it carefully.  I don't intend to do anything with Firebug other than have it installed, since that seems to be enough.

Jonathan, if/when you get a chance to bisect, and you are able to determine which add-on is at fault (assuming one is), can you please file a new bug?  Thanks.

	Jan Honza Odvarko [:Honza] (always need-info? me)
	Comment 29 • 12 years ago

(In reply to Wolfgang Rosenauer [:wolfiR] from comment #25)
> Please note that I didn't use Firebug in most cases. It was just installed
> because I need to from time to time. Version is 1.10.6 fwiw.
> I'll will still watch it but wanted to let you know since I'm pretty sure
> about it.

Note that Firebug is loaded lazily - when the user opens the UI (e.g. F12) for the first time, see: https://blog.getfirebug.com/2012/01/27/firebug-1-10a2/

This means that even if Firebug extension is installed only a few browser overlays are applied (e.g. 'Inspect Element with Firebug' page context menu item, 'Start Button' in Firefox toolbar and Firefox menu). In this case chances of memory leaks caused by Firebug are noticeably smaller...

Did you open Firebug at least once during the testing?


(In reply to Nicholas Nethercote [:njn] from comment #28)
> I just installed Firebug 1.10.6 on my Linux64 day-to-day browser instance. 
> I'll watch it carefully.  I don't intend to do anything with Firebug other
> than have it installed, since that seems to be enough.
I am very interested in the results!

Note that 'extensions.firebug.delayLoad' should be set true (by default) to have Firebug lazily loaded.

Honza

	Wolfgang Rosenauer [:wolfiR] Reporter
	Comment 30 • 12 years ago

(In reply to Jan Honza Odvarko from comment #29)
> Did you open Firebug at least once during the testing?

No.
But now with firebug disabled Aurora is running the second day w/o any memory issues whereas it was a matter of a few hours before.

	Jan Honza Odvarko [:Honza] (always need-info? me)
	Comment 31 • 12 years ago

(In reply to Wolfgang Rosenauer [:wolfiR] from comment #30)
> (In reply to Jan Honza Odvarko from comment #29)
> > Did you open Firebug at least once during the testing?
> 
> No.
> But now with firebug disabled Aurora is running the second day w/o any
> memory issues whereas it was a matter of a few hours before.
Could you please repeat your testing with Firebug 1.11?
https://getfirebug.com/releases/firebug/1.11/firebug-1.11.0b2.xpi

Honza

	Nicholas Nethercote [inactive]
	Comment 32 • 12 years ago

(In reply to Nicholas Nethercote [:njn] from comment #28)
> I just installed Firebug 1.10.6 on my Linux64 day-to-day browser instance. 
> I'll watch it carefully.  I don't intend to do anything with Firebug other
> than have it installed, since that seems to be enough.

After 24 hours my "heap-unclassified" is at 11.32% and memory consumption is perfectly normal.  I'll try initializing Firebug (via F12) and then deactivating it and see what happens.

	Wolfgang Rosenauer [:wolfiR] Reporter
	Comment 33 • 12 years ago

(In reply to Jan Honza Odvarko from comment #31)
> (In reply to Wolfgang Rosenauer [:wolfiR] from comment #30)
> > (In reply to Jan Honza Odvarko from comment #29)
> > > Did you open Firebug at least once during the testing?
> > 
> > No.
> > But now with firebug disabled Aurora is running the second day w/o any
> > memory issues whereas it was a matter of a few hours before.
> Could you please repeat your testing with Firebug 1.11?
> https://getfirebug.com/releases/firebug/1.11/firebug-1.11.0b2.xpi

Running with 1.11.0b2 now almost two days with no memory issues. No other changes done.

	Nicholas Nethercote [inactive]
	Comment 34 • 12 years ago

> After 24 hours my "heap-unclassified" is at 11.32% and memory consumption is
> perfectly normal.  I'll try initializing Firebug (via F12) and then
> deactivating it and see what happens.

I couldn't reproduce the problem with Firebug 1.10.6.  It's a shame, I'd love to know what Firebug is doing that the memory reporters are missing.

Stephan, can you try 1.11.0b2?  If that version fixes the problem for you, then I think we can spin off Johnathan's problem as a separate bug report and declare victory here.

	Stephan Sokolow
	Comment 35 • 12 years ago

(In reply to Nicholas Nethercote [:njn] from comment #34)
> Stephan, can you try 1.11.0b2?  If that version fixes the problem for you,
> then I think we can spin off Johnathan's problem as a separate bug report
> and declare victory here.

Lately, the problem has been a bit hard to reliably trigger but I'll give that a try and I'll try to remember to force Firebug to get loaded.

(Lately, it always starts after I fall asleep and Firefox always gets OOM-killed before I wake up but it doesn't happen every single night... possibly because I don't activate Firebug's DOM inspector every single day.)

	Kris Maglione [:kmag]
	Comment 36 • 12 years ago

Can we call this fixed at this point? Also, do we have any idea whether it was caused/fixed by a Firefox update or a Firebug update?

	Stephan Sokolow
	Comment 37 • 12 years ago

Seems to be fixed. It's been about a week and the memory leaks seem to be back to the old "leaks its way up to 4GiB over the course of several weeks" behaviour that I've been used to since at least Firefox 4.

	Nicholas Nethercote [inactive]
	Comment 38 • 12 years ago

Good enough for me.  Jonathan, if you are still seeing your problem can you please file a new bug?

	Anand Kumria
	Comment 40 • 12 years ago

I'm not sure that this can be called fixed.

With: Build identifier: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0

And the current version of firebug (1.10.6), I have excessive CPU usage and a relatively high amount of heap unclassified.

The only common plugins with prior reporters are: firebug, adblock plus, ghostery and lazarus forms.

I've attached my about:memory?verbose, as instructed by the #memshrink channel.

	Nicholas Nethercote [inactive]
	Comment 41 • 12 years ago

> And the current version of firebug (1.10.6), I have excessive CPU usage and
> a relatively high amount of heap unclassified.

Try Firebug 11.0.0b2, as per comment 33.

	Jonathan Protzenko [:protz]
	Comment 42 • 12 years ago

I haven't had the problem in a while, so I guess it's fixed somehow now :)