638238 - Large memory increase in firefox while minimized

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Hugh Nougher [:Hughman]]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12) Gecko/20100101 Firefox/4.0b12
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b12) Gecko/20100101 Firefox/4.0b12

I have seen a memory increase problem related to having the firefox window minimized. I do not know exactly how to replicate but I saw it again just now and I think it could cause crashes of firefox while in the minimized state.

Reproducible: Sometimes

Steps to Reproduce:
1. Run normal session (I usually have multiple tabs and addons).
2. Minimize firefox. Memory usage is still normal at this point (~400MB).
3. Leave for a few hours. Sometimes the memory usage can easily pass 1.5GB now, sometimes its reached 2.6GB though not since beta12.
4. Restore/Maximize firefox. Memory usage quickly drops back to a more reasonable level (~650MB).


Expected Results:  
Memory usage should stay at reasonable levels.

Things I suspect as being related but have not looked further into:
- Download window open and mod way through download when the windows are minimized.
- RSS Ticker appears and displays new items while window is minimized.

I just happened to get an about:memory ~3 seconds after restoring the window this time which I will attach along with about:memory a few minuts later which I hope will help. The 2 most interesting this to see other than the global use is 184,318,536 js/string-data reducing to 7,378,842 and js/gc-heap at 291,504,128.

Comment 1

[Hugh Nougher [:Hughman]]

Attachment: about:memory after ~3 sec and a few minutes later

Comment 2

[Boris Zbarsky [:bzbarsky]]

Are we failing to gc or cc (or both?) while minimized?

Comment 3

[Olli Pettay [:smaug][[e-mail]]]

GC/CC handling doesn't depend on window being minimized.


Which addons do you have?

Comment 4

[Andreas Gal :gal]

Something is making a ton of string data while the browser is minimized. Our GC heuristics mostly triggers on GC header allocations. If you make a ton of large strings, I guess we don't poke the GC as aggressively. The 1.5GB vs 2.6GB is likely the additional GCs we do while unused chunks are being held. Add-ons is a pretty good question here. And also, what tabs are open while minimized. Does that make a difference?

Comment 5

[Hugh Nougher [:Hughman]]

The above details are nearly everything I have been able to see as common for this to happen. I do not believe its based on which tabs are open since I nearly always have the same 20 tabs open, though I cant rule it out. Even with my addons it does not happen half the time and the only common link I have seen between the times the problem occurs is "RSS Ticker appears and displays new items while window is minimized". I might try new profiles with various ideas around this if I find time.

Will attach Extension section of about:support for my addon list.

Comment 6

[Hugh Nougher [:Hughman]]

Attachment: Addon list

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #5)
> I do not believe its based on which tabs are open since I
> nearly always have the same 20 tabs open, though I cant rule it out.
Especially if you have the *same* tabs open, it might be useful to know which ones. Some of those could cause lots of memory usage.

> Even with
> my addons it does not happen half the time and the only common link I have seen
> between the times the problem occurs is "RSS Ticker appears and displays new
> items while window is minimized". I might try new profiles with various ideas
> around this if I find time.
Could you try with safe mode which disables addons?
Or could you try disabling addons one by one from addon manager?
I'd start with RSS Ticker.

Comment 8

[Hugh Nougher [:Hughman]]

I regards to tabs I'll elaborate a bit. It the same or very similar open most of the time (similar by web programmer pov), even on the times that no memory problem at all is seen. In any case my normal set include ~2 "Server not found pages" (this is because its to a site which loads a lot of data via javascript so I use the back button then refesh rather than leave it using bandwidth with im not around, actual sites are tbpl.mozilla.org and www.arewefastyet.com), a number of tabs from www.mangafox.com and the rest from sites that appear to be almost static.

The biggest problem in working it out what the real cause is would be I dont know a way to reliably reproduce and only occurs once every few days. So disabling the addons one by one is not going to get us anywhere as far as I can forsee. It also likely requires > 12 hours in minimized mode (while asleep and/or at work) to reach the large levels.

I am running a few trials in some -no-remote instances with new profiles and seeing some slow memory increase but its not high enough to say its not normal yet (win task manager says ~130MB in use when I started this post, 145MB now, 45min later).

Does anyone know a tool which can grab and graph memory usage of a given process in windows? Something like the test pilot "week in the life of a browser v2" memory graph would be useful for these long running tests.

Comment 9

[Hugh Nougher [:Hughman]]

Attachment: Results of some trials

Results of the trials are in (its been a long day). I believe this should rule out what is in the tabs and addons as the base of the problem. The RSS Ticker seems to have simply accelerated the process.

The first trial instance seems to have caught hold of the problem nicely showing a 30MB increase every two hours before dropping sharply when restored.

Second trial seems to have triggered a garbage collection at various intervals though still showing 40MB increase every two hours when between two collections (pitty there was a collection just before the 9hrs was up).

Third and Fourth could be taken as base lines which still show a 1MB per 2hrs rise (no idea why) and a small drop when restored.

So after all that, the following is a likely way to reproduce in a short amount of time:
1. New profile with RSS Ticker showing default feed, or other feed which updates a lot.
1b. I also set options Hide when empty and ran Mark All as Read before starting though I think these steps should not matter.
2. Minimize and leave for 1-2 hours. This should be long enough to reach 150MB or more used, needed since GC'ed reached 130MB in these trials.
3. View memory usage in OS's process viewer (like Windows Task Manager).
4. Restore window (memory usage starts going down immeadiately).
5. View memory usage in OS's process viewer again.

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #8)
>  actual sites are tbpl.mozilla.org...
That is probably *a* problem. tbpl is known to cause lots of memory usage over time, at least it
used to do so.

Comment 11

[Hugh Nougher [:Hughman]]

I tested the Firefox 4 Release Candidate against the steps I gave in comment 9 and was able to reproduce.
I also noticed that for this test the GC does seem run at some point > 250MB so its only really a minor issue unless the 'items' that are not being used for triggering the GC are used in large amounts, whatever they might be.

Comment 12

[Hugh Nougher [:Hughman]]

Just found an even quicker way to get results.
Open http://glow.mozilla.org/ in a tab, minimize for half and hour, 150MB in use, restore, 100MB in use.
My test this time was in latest minefield with the only addon being test pilot (which seems to be installed by default).

Comment 13

[Peter Steinbrueck]

about:memory open in one tab and refreshing it from time to time seems to help a little. 
With every refresh of about:memory mem usage drops back to the level when I had opened about:memory. 
(NT6.1 x64, FF4.0 in safe mode, app. 20 tabs open)

Comment 14

[Nicholas Nethercote [inactive]]

(In reply to comment #0)
>
> The 2 most interesting this to see other than the
> global use is 184,318,536 js/string-data reducing to 7,378,842 and
> js/gc-heap at 291,504,128.

Note that the js/string-data reporter is utterly unreliable in FF 4.0, unfortunately.  Bug 648490 removed it for that reason, bug 571249 will add a fixed version back in.

Comment 15

[Hugh Nougher [:Hughman]]

After looking over what I said above after so long and with my better knowledge of the existing memory bugs, this looks like the idle GC problem which I think is covered by bug 656120.

When I get a chance I will check this over again and compare results to the idle GC problem. I would like to keep this open until this is confirmed.

Comment 16

[Nicholas Nethercote [inactive]]

Hugh: it's very likely that bug 656120 has fixed this problem.  Can you please try a nightly build (nightly.mozilla.org) and let us know if it has been fixed?  Thanks.

Comment 17

[Hugh Nougher [:Hughman]]

I tested this against the Nightly of 2011-06-20 and 2011-06-21 where bug 656120 was landed using the http://glowfx4.mozilla.org/ as the testcase (tests already running by the time comment 16 was made, thanks anyway Nick).

Result:
- 2011-06-20 had this problem.
- 2011-06-21 was nice and smooth apart from bug 650649.

I also tested with RSS Ticker and found nothing worth noting around memory rise.
So I am marking this as working for me.

Comment 18

[Nicholas Nethercote [inactive]]

"WORKSFORME" means "I don't see the original problem".  I'll change this to FIXED.

Thanks for the quick confirmation!