Categories
about:memory Firefox Memory consumption MemShrink

Leak reports triage, May 24, 2011

I’ve been tracking recent memory leak reports in bug 640452. I’m doing this because I think memory leaks hurt Firefox, in terms of losing users to other browsers, as much as any other single cause. (I suspect pathological performance slow-downs due to old and busted profiles hurt almost as much, but that’s a topic for another day.)

There are 61 bugs tracked by bug 640452, 21 of which have been resolved.  Any and all help with the 40 remaining would be most welcome. For each bug I’ve put in square brackets a summary of the action I think it needs.

  • [NEEDS ANALYSIS]:  needs someone to attempt to reproduce, try to work out if the problem is real and still occurring.
  • [NEEDS WORK]: problem is known to be real, needs someone to actually fix it.
  • [PENDING EVANGELISM]: problem with a website is causing a leak, needs someone to check the site has been fixed.
  • [CLOSE?]: bug report is unlikely to go anywhere useful.  Closing it (with a gentle explanation) is probably the best thing to do.
  • [GGC]: needs generation GC to be fixed properly.

Here are the bugs.

  • 497808: This is a leak in gmail, caused by a bug in gmail — when an email editing widget is dismissed, some stuff isn’t unlinked from a global object that should be.  Google Chrome also leaks, but a smaller amount, it’s unclear why. The bug is assigned to Peterv and is still open pending confirmation that it’s been fixed in gmail. [PENDING EVANGELISM]
  • 573688: Valgrind detects several basic leaks in SQLite.  Assigned to Sayre, no progress yet. [NEEDS WORK]
  • 616850: Huge heaps encountered when browsing www.pixiv.net, leading to incredibly slow cycle collections (3 minutes or more!)  Little progress. [NEEDS ANALYSIS]
  • 617569: Large heaps encountered for some pages using web workers.  Looks like it’s not an actual leak.  Assigned to Gal, he says a generational GC would help enormously, so probably nothing will happen with this bug until that is implemented (which is planned).  I marked it as depending on bug 619558. [GGC]
  • 624186: Using arguments.callee.caller from a JSM can trigger an xpcom leak.  The bug has a nice small test that demonstrates the problem.  Unassigned. [NEEDS WORK]
  • 631536: A bad string leak, seemingly on Windows only, with lots of discussion and a small test case.  Assigned to Honza Bambas.  Was a Firefox 4.0 blocker that was changed to a softblocker at the last minute without any explanation.  Seems close to being fixed. [NEEDS WORK]
  • 632012: Firefox 4 with browser.sessionstore.max_concurrent_tabs=0 uses a lot more memory restoring a session with 100s of tabs than Firefox 3.6 with BarTab.  Unassigned.  Unclear if this is a valid comparison.  [CLOSE?]
  • 634156: Identifies some places where the code could avoid creating sandboxes.  Assigned to Mrbkap, he said (only four days ago) he has a patch in progress.  Seems like it’s not actually a leak, so I changed it to block bug 640457 (mslim-fx5+). [NEEDS WORK]
  • 634449: A classic not-very-useful leak report.  One user reported high and increasing memory usage with vague steps to reproduce.  Two other users piled on with more vague complaints.  The original reporter didn’t respond to requests for more measurements with a later version.  I’m really tempted to close bugs like this, they’ll never lead anywhere.  Unassigned. [CLOSE?]
  • 634895: Vague report of memory usage increasing after awakening a machine after hibernation, with one “me too” report.  Unassigned.  Unlikely to lead to any useful changes.  [CLOSE?]
  • 635121: A leak in Facebook Chat, apparently it’s Facebook’s fault and occurs in other browsers too.  (Unfortunately, leaks like that hurt us disproportionately because we don’t have process separation.)  Assigned to Rob Arnold, marked as a Tech Evangelism bug.  Unclear if the Facebook code has been fixed, or if Facebook has even been contacted. [PENDING EVANGELISM]
  • 635620: Very vague report.  Unlikely to go anywhere.  Unassigned. [CLOSE?]
  • 636077: Report of increasing memory usage, with good test case.  Lots of discussion, but unclear outcomes.  Again, generational GC could help.  MozMill endurance tests showed the memory increase flattening out eventually.  Might be worth re-measuring now.  Assigned to Gal.  I marked it as depending on the generational GC bug (bug 619558). [NEEDS ANALYSIS, GGC]
  • 636220: Memory usage remains high after closing Google Docs tabs.  Assigned to Gal.  Needs more attempts to reproduce. [NEEDS ANALYSIS]
  • 637449: Looks like a clear WebGL leak.  Might be a duplicate of, or related to, bug 651695. Unassigned, but Bjacob looked into it a bit. [NEEDS ANALYSIS]
  • 637782: Memory usage increases on image-heavy sites like http://www.pixdaus.com/ or http://boston.com/bigpicture/ or http://www.theatlantic.com/infocus/.  Lots of discussion but not much progress.  Unclear if the memory is being released eventually.  Needs more analysis.  Unassigned.  [NEEDS ANALYSIS]
  • 638238: Report of memory increasing greatly while Firefox is minimized.  Might be related to RSS Ticker?  I would recommend giving up on this one except the reporter is extremely helpful (he’s participated in multiple bugs and I’ve chatted to him on IRC) and so progress might still be made with some effort.  Unassigned. [NEEDS ANALYSIS]
  • 639186: AdBlock Plus and NoScript together causing a leak on a specific page.  Lots of discussion but it petered out.  Unassigned.  [NEEDS ANALYSIS]
  • 639515: GreaseMonkey causes a big memory spike when entering private browsing.  Some discussion that went nowhere.  Unassigned.  [NEEDS ANALYSIS]
  • 639780: Report of steadily increasing memory usage leading to OOMs.  Steps to reproduce are vague, but the reporter is very helpful and collected lots of data.  Unassigned.
  • 640923: Vague reports of increasing memory usage, lots of people have piled on.  One useful lead:  RSS feeds might be causing problems on Windows 7?  The user named SineSwiper (who has alternated between being abusive and collecting useful data) thinks so.  Unassigned. [NEEDS ANALYSIS]
  • 642472: High memory usage on a mapping site.  Very detailed steps to reproduce;  one other user couldn’t reproduce.  Unassigned.  [NEEDS ANALYSIS]
  • 643177: Vague report.  Unassigned.  [CLOSE?]
  • 643940: Ehsan found leaks in the HTML5 parser with the OS X ‘leaks’ tool.  Unassigned.  [NEEDS ANALYSIS]
  • 644073: Ehsan found a shader leak with the OS X ‘leaks’ tool.  Unassigned. [NEEDS WORK]
  • 644457: High memory usage with gawker websites and add-ons (maybe NoScript?)  See comment 25. Unassigned.  [CLOSE?]
  • 644876: Leak with AdBlock Plus and PageSpeed add-ons on mapcrunch.com.  Unassigned.  [NEEDS ANALYSIS]
  • 645633: High memory usage with somewhat detailed steps to reproduce.  Reporter is helpful and has collected various pieces of data.  [NEEDS ANALYSIS]
  • 646575: Creating sandboxes causes leaks.  Good test case.  Unassigned.  [NEEDS WORK]
  • 650350: Problem with image element being held onto when image data has been released.  Bz said he would look at it.  Unassigned. [NEEDS ANALYSIS]
  • 650649: with only about:blank loaded, memory usage ticks up slightly.  Some discussion;  it may be due to the Urlclassifier downloading things.  If that’s true, it makes diagnosing leaks difficult. [NEEDS ANALYSIS]
  • 651695: Huge WebGL leak in the CubicVR demo.  Unassigned.  [NEEDS WORK]
  • 653817: Memory increase after opening and closing tabs.  A lot of discussion has happened, it’s unclear if the memory usage is due to legitimate things or if it’s an actual leak.  Assigned to me.  [NEEDS ANALYSIS]
  • 653970: High memory usage on an image-heavy site.  Comment 5 has a JS snippet that supposedly causes OOM crashes very quickly.  Unassigned.  [NEEDS ANALYSIS]
  • 654028: High memory usage on Slashdot.  Seems to be because Slashdot runs heaps of JavaScript when you type a comment.  Lots of discussion, seems to be due to bad GC heuristics and/or lack of generational GC?  Unclear if there’s an actual leak, or just delayed GC.  Unassigned.  [NEEDS ANALYSIS]
  • 654820: Leak in JaegerMonkey’s regular expression code generator caught by assertions.  Assigned to cdleary.  [NEEDS WORK]
  • 655227: Timers using small intervals (100ms or less) are never garbage collected(!)  Unassigned.  [NEEDS ANALYSIS]
  • 656120: Bug to do GC periodically when the browser is idle.  Assigned to Gwagner, has a patch.  [NEEDS WORK]
  • 657658: test_prompt.html leaks.  Unassigned.  [NEEDS WORK]

You can see that most bugs are marked as “[NEEDS ANALYSIS]”.  The size of the problem and the amount of developer attention it is receiving are not in proportion.

One thing I want to do is write a wiki page explaining how to submit a useful leak report, in an attempt to avoid the vague reports that never go anywhere.  But the improved about:memory is a big part of that, and it won’t land until Firefox 6.  I’m wondering if the about:memory changes should be backported to Firefox 5 in an attempt to improve our leak reports ASAP.

Another thing I’m wondering about is being more aggressive about closing old leak reports.  We have 624 open bugs that have the “mlk” keyword (including some recent ones that aren’t in the list above).  The oldest of these is bug 39323 which was filed in May 2000.  Surely most of these aren’t relevant any more?  It’s good to have a mechanism for tracking leaks (be it a keyword or a tracking bug) but if most such bugs are never closed, the mechanism ends up being useless.  I’d love to hear ideas about this.

Finally, I’d like to hear if people think this blog post is useful;  I’m happy to make it an ongoing series if so, though regular MemShrink meetings would be more effective.

 

17 replies on “Leak reports triage, May 24, 2011”

I think that lists of priorities of about anything with firefox and things is good. With the mess of bugs on bugzilla.. its hard to really have a list of priorities… With lists it encourages people to take up things they would not have taken up otherwise…

Besides https://wiki.mozilla.org/Firefox/Features
I don’t know of any real lists of bugs made for “goals” for future development. I’d like it if there was a place for people to nominate things that they want done. Though my current biggest pet peve is just that the bookmark manager needs to be reskined.

So um.. yes.. keep doing these posts in the future 😀

I think creating that page on reporting good leak bugs and then closing the vague and old ones with a reference to that one and some comment on “please follow that guide with a current version and reopen or file a new bug with the detailed info if it still can be reproduced” is probably a good way to go.

And thanks a lot for looking into this matter! People complaining about memory usage, esp. when running Firefox for a long time, are the largest group of complaints I’m hearing recently (and, of course, making us leaner on memory helps us running more smoothly on the rising mobile market).

Anything that helps ordinary users like myself understand the bugzilla process is a good idea.
I would certainly find a wiki useful, about how to submit useful leak reports.

(and for that matter improved documentation on how to submit other bugz)

I am often on the Firefox support feedback forum where there are a lot of reports of memory problems, or firefox being slow in relation to OOP & plugincontainer. The Firefox support KB top requested article being about plugin crashes, having currently nearly 60k visits per week. (https://support.mozilla.com/en-US/contributors)

“One thing I want to do is write a wiki page explaining how to submit a useful leak report, in an attempt to avoid the vague reports that never go anywhere.”

This would be great.

I’ve been helping maintain http://support.mozilla.com/en-US/kb/High%20memory%20usage (aimed at advanced users) and https://wiki.mozilla.org/Performance:Leak_Tools (aimed at Firefox developers). Also having a page aimed at bug reporters would make a lot of sense.

It might be good to include on some of these pages:

* How to tell if your main symptoms (e.g. crash or slowness) are actually caused by high memory use.

* How much memory Firefox is “expected” to use for a given number of tabs or session length, so you can tell whether yours is “abnormally high”.

* How to tell the difference between a web site leak bug and a Firefox leak bug.

* How much progress we’re making on improving memory use. So that bug reporters understand that (1) closing a vague bug report doesn’t mean we’re “ignoring leaks” and (2) if they put the effort into getting more information, their bug is likely to be fixed.

“Another thing I’m wondering about is being more aggressive about closing old leak reports.”

Yes. Aggressively mark vague leak bugs as INCOMPLETE. This is what I did when I triaged bugs:

https://bugzilla.mozilla.org/show_bug.cgi?id=407624#c1
https://bugzilla.mozilla.org/show_bug.cgi?id=424360#c1
https://bugzilla.mozilla.org/show_bug.cgi?id=453183#c1

I like your approach with whiteboard markers for the bugs that don’t get marked as INCO. It’s similar to what I did with the big crash bug triage described in https://developer.mozilla.org/En/Triaging_crash_bugs 🙂

“But the improved about:memory is a big part of that, and it won’t land until Firefox 6. I’m wondering if the about:memory changes should be backported to Firefox 5 in an attempt to improve our leak reports ASAP.”

We often ask bug reporters to test on nightlies anyway, so I don’t think it’s especially important to backport the about:memory changes.

Isn’t part of the issue that there are two classes of bug reports:

“interesting” bug reports presumably leading to questionable and fixable code behaviour

vs

“coarse observation from afar”-type “supporting” bug reports (or “leaks observed with site XYZ”): probably only useful within larger bug-conglomerates for *test cases to check improvement. Keep them around a bit, ask for periodic retesting or additional observations. Otherwise let them _GRACEFULLY_AGE_ into obsolescence unless the report manages to class-change into an interesting report.

(maybe downgrade priority regularly / add another obsolete-for-N-years tag once a year? However this needs a small tweak with search/… to allow down-sorting/filtering of these lower-pri bugs).

Does firefox have a tag-scheme to distinguish these cases and channel developer attention?

BTW thanx for your work with the metabug tracking!

Peter: yes, my mlk-* system is meant to provide exactly this “graceful aging into obsolesence” (nice way of describing it!) It doesn’t explicitly distinguish “interesting” and “coarse” bugs, but my hypothesis is that “interesting” bugs have a high chance of being fixed quickly, and therefore older bugs are more likely to be “coarse”.

As for applying this system to all bugs… I’m not sure it will scale that well. And I think leak reports are particularly prone to undetected duplication and staleness, and so warrant a more complex tracking system. But that’s mostly just my gut feeling as I haven’t tried this new system out yet 🙂

By Post Author

Addendum: tomorrows mlk-* tagging blog entry implements something similar to part of my sketch above.

* If mlk*-tagging proves to be useful, please argue
* to do something similar with ALL BUGS, not just
* the ff4+ memory leaks.

Tagging, “aging-into-obsolescense” and better “priorizing” bugs in search output isn’t only useful for developer efficiency, but also quite helpful to *USERS* looking for bugs and possible work-arounds describing their very own problem. Might also keep down dupe reports.

thanx,
Peter

“Finally, I’d like to hear if people think this blog post is useful…”

This post is VERY USEFUL, at least for Bugzilla@Mozilla users like me. 😉

Thank you for this. I haven’t been active w/ Bugzilla but I upgraded to FF4 last week and have had nothing but slow and painful (can open 10 or 15 tabs but then if I leave and come back they turn to molasses, e.g. several attempts over several minutes to close a tab). Probably not what you were trying to help with, but skimming a compilation like this is *much* easier than trying to flail around in my search hits and hope to hit the right thing. Have a plan A, B, C, and D to try now so that I don’t have to put up w/ IE8’s buggy tabs. (8 And for the future I would *love* to know how to report these things usefully.

Michelle: try a Firefox 5 beta (beta.mozilla.org), it’s memory usage is quite a bit better than Firefox 4’s, though not as good as 3.6’s. It might be enough to fix your problems.

By Post Author

I think I’ve reported it already but I don’t see it above – really not gonna post bug reports anymore as I’ll just get a reply six months later saying I should try again with the latest build.

Basically, when using a site that has a meta refresh or some javascript forcing page reload every 10-30 seconds, Firefox will keep allocating memory until it goes over 2 GB on a 32 bit OS.

An example of such site that can cause crashes is gamecopyworld dot com (you have to pick a mirror and then click on Enter button on next page). Leaving that page with list of games open in the browser, will cause firefox to use memory a lot.

Comments are closed.