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]
- 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.