{"id":790,"date":"2011-05-24T12:47:38","date_gmt":"2011-05-24T01:47:38","guid":{"rendered":"http:\/\/blog.mozilla.org\/nnethercote\/?p=790"},"modified":"2011-05-24T12:47:38","modified_gmt":"2011-05-24T01:47:38","slug":"leak-reports-triage-may-24-2011-2","status":"publish","type":"post","link":"https:\/\/blog.mozilla.org\/nnethercote\/2011\/05\/24\/leak-reports-triage-may-24-2011-2\/","title":{"rendered":"Leak reports triage, May 24, 2011"},"content":{"rendered":"<p>I&#8217;ve been tracking recent memory leak reports in <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=mlk-fx5%2B\">bug 640452<\/a>.  I&#8217;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&#8217;s a topic for another day.)<\/p>\n<p>There are 61 bugs tracked by <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=mlk-fx5%2B\">bug 640452<\/a>, 21 of which have been resolved.\u00a0 Any and all help with the 40 remaining would be most welcome. For each bug I&#8217;ve put in square brackets a summary of the action I think it needs.<\/p>\n<ul>\n<li>[NEEDS ANALYSIS]:\u00a0 needs someone to attempt to reproduce, try to work out if the problem is real and still occurring.<\/li>\n<li>[NEEDS WORK]: problem is known to be real, needs someone to actually fix it.<\/li>\n<li>[PENDING EVANGELISM]: problem with a website is causing a leak, needs someone to check the site has been fixed.<\/li>\n<li>[CLOSE?]: bug report is unlikely to go anywhere useful.\u00a0 Closing it (with a gentle explanation) is probably the best thing to do.<\/li>\n<li>[GGC]: needs generation GC to be fixed properly.<\/li>\n<\/ul>\n<p id=\"comment_text_0\">Here are the bugs.<\/p>\n<ul>\n<li><a title=\"ASSIGNED - GMail window leak\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=497808\">497808<\/a>: This is a leak in gmail, caused by a bug in gmail &#8212; when an email editing widget is dismissed, some stuff isn&#8217;t unlinked from a global object that should be.\u00a0 Google Chrome also leaks, but a smaller amount, it&#8217;s unclear why. The bug is assigned to Peterv and is still open pending confirmation that it&#8217;s been fixed in gmail. [PENDING EVANGELISM]<\/li>\n<li><a title=\"NEW - sqlite leaks a bunch\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=573688\">573688<\/a>: Valgrind detects several basic leaks in SQLite.\u00a0 Assigned to Sayre, no progress yet. [NEEDS WORK]<\/li>\n<li><a title=\"UNCONFIRMED - Huge CC pauses when using AutoPagerize userscript on pixiv\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=616850\">616850<\/a>: Huge heaps encountered when browsing www.pixiv.net, leading to incredibly slow cycle collections (3 minutes or more!)\u00a0 Little progress. [NEEDS ANALYSIS]<\/li>\n<li><a title=\"NEW - High CPU load and memory leak with web workers\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=617569\">617569<\/a>: Large heaps encountered for some pages using web workers.\u00a0 Looks like it&#8217;s not an actual leak.\u00a0 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).\u00a0 I marked it as depending on <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=619558\">bug 619558<\/a>. [GGC]<\/li>\n<li><a title=\"NEW - Arguments.callee.caller leaks a docshell, window, etc when spanning a JSM boundary\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=624186\">624186<\/a>: Using arguments.callee.caller from a JSM can trigger an xpcom leak.\u00a0 The bug has a nice small test that demonstrates the problem.\u00a0 Unassigned. [NEEDS WORK]<\/li>\n<li><a title=\"NEW - Constantly raising private bytes allocation on a web page\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=631536\">631536<\/a>: A bad string leak, seemingly on Windows only, with lots of discussion and a small test case.\u00a0 Assigned to Honza Bambas.\u00a0 Was a Firefox 4.0 blocker that was changed to a softblocker at the last minute without any explanation.\u00a0 Seems close to being fixed. [NEEDS WORK]<\/li>\n<li><a title=\"UNCONFIRMED - Firefox 4 uses 300% more memory for delayed session restore (comparing Firefox 4 with browser.sessionstore.max_concurrent_tabs=0 against Firefox 3.6 with BarTab)\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=632012\">632012<\/a>: 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.\u00a0 Unassigned.\u00a0 Unclear if this is a valid comparison.\u00a0 [CLOSE?]<\/li>\n<li><a title=\"NEW - ConsoleAPI.js and InstallTrigger.js should not use sandboxes\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=634156\">634156<\/a>: Identifies some places where the code could avoid creating sandboxes.\u00a0 Assigned to Mrbkap, he said (only four days ago) he has a patch in progress.\u00a0 Seems like it&#8217;s not actually a leak, so I changed it to block <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=mslim-fx5%2B\">bug 640457<\/a> (mslim-fx5+). [NEEDS WORK]<\/li>\n<li><a title=\"UNCONFIRMED - Latest minefield builds have severe memory leaks or extremely high memory usage\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=634449\">634449<\/a>: A classic not-very-useful leak report.\u00a0 One user reported high and increasing memory usage with vague steps to reproduce.\u00a0 Two other users piled on with more vague complaints.\u00a0 The original reporter didn&#8217;t respond to requests for more measurements with a later version.\u00a0 I&#8217;m really tempted to close bugs like this, they&#8217;ll never lead anywhere.\u00a0 Unassigned. [CLOSE?]<\/li>\n<li><a title=\"NEW - Memory usage increases after each time the computer wakes up from hibernation (sleep)\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=634895\">634895<\/a>: Vague report of memory usage increasing after awakening a machine after hibernation, with one &#8220;me too&#8221; report.\u00a0 Unassigned.\u00a0 Unlikely to lead to any useful changes.\u00a0 [CLOSE?]<\/li>\n<li><a title=\"NEW - Suspected memory leak involving Facebook JS in app tab\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=635121\">635121<\/a>: A leak in Facebook Chat, apparently it&#8217;s Facebook&#8217;s fault and occurs in other browsers too.\u00a0 (Unfortunately, leaks like that hurt us disproportionately because we don&#8217;t have process separation.)\u00a0 Assigned to Rob Arnold, marked as a Tech Evangelism bug.\u00a0 Unclear if the Facebook code has been fixed, or if Facebook has even been contacted. [PENDING EVANGELISM]<\/li>\n<li><a title=\"UNCONFIRMED - Firefox never frees memory when leaving a website. After a few websites starts to hang.\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=635620\">635620<\/a>: Very vague report.\u00a0 Unlikely to go anywhere.\u00a0 Unassigned. [CLOSE?]<\/li>\n<li><a title=\"REOPENED - when idle, memory slowly increases on betanews.com and it takes a long time until we GC\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=636077\">636077<\/a>: Report of increasing memory usage, with good test case.\u00a0 Lots of discussion, but unclear outcomes.\u00a0 Again, generational GC could help.\u00a0 MozMill endurance tests showed the memory increase flattening out eventually.\u00a0 Might be worth re-measuring now.\u00a0 Assigned to Gal.\u00a0 I marked it as depending on the generational GC bug (<a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=619558\">bug 619558<\/a>). [NEEDS ANALYSIS, GGC]<\/li>\n<li><a title=\"NEW - WebGL websites do not release memory after being closed\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=637449\">636220<\/a>: Memory usage remains high after closing Google Docs tabs.\u00a0 Assigned to Gal.\u00a0 Needs more attempts to reproduce. [NEEDS ANALYSIS]<\/li>\n<li><a title=\"NEW - WebGL websites do not release memory after being closed\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=637449\">637449<\/a>: Looks like a clear WebGL leak.\u00a0 Might be a duplicate of, or related to, <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=651695\">bug 651695.<\/a> Unassigned, but Bjacob looked into it a bit. [NEEDS ANALYSIS]<\/li>\n<li><a title=\"NEW - Memory not being released after visiting image heavy sites\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=637782\">637782<\/a>: Memory usage increases on image-heavy sites like<a href=\"http:\/\/www.pixdaus.com\/\"> http:\/\/www.pixdaus.com\/<\/a> or <a href=\"http:\/\/boston.com\/bigpicture\/\">http:\/\/boston.com\/bigpicture\/<\/a> or <a href=\"http:\/\/www.theatlantic.com\/infocus\/\">http:\/\/www.theatlantic.com\/infocus\/<\/a>.\u00a0 Lots of discussion but not much progress.\u00a0 Unclear if the memory is being released eventually.\u00a0 Needs more analysis.\u00a0 Unassigned.\u00a0 [NEEDS ANALYSIS]<\/li>\n<li><a title=\"NEW - Large memory increase in firefox while minimized\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=638238\">638238<\/a>: Report of memory increasing greatly while Firefox is minimized.\u00a0 Might be related to RSS Ticker?\u00a0 I would recommend giving up on this one except the reporter is extremely helpful (he&#8217;s participated in multiple bugs and I&#8217;ve chatted to him on IRC) and so progress might still be made with some effort.\u00a0 Unassigned. [NEEDS ANALYSIS]<\/li>\n<li><a title=\"UNCONFIRMED - Using Adblock Plus and NoScript together causing memory leak\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=639186\">639186<\/a>: AdBlock Plus and NoScript together causing a leak on a specific page.\u00a0 Lots of discussion but it petered out.\u00a0 Unassigned.\u00a0 [NEEDS ANALYSIS]<\/li>\n<li><a title=\"NEW - Greasemonkey 0.9.1 causes memory leak on entering\/exiting private browsing mode\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=639515\">639515<\/a>: GreaseMonkey causes a big memory spike when entering private browsing.\u00a0 Some discussion that went nowhere.\u00a0 Unassigned.\u00a0 [NEEDS ANALYSIS]<\/li>\n<li><a title=\"UNCONFIRMED - Significant memory leak introduced between 4.0b10 and 4.0b12; causing regular system OOMs\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=639780\">639780<\/a>: Report of steadily increasing memory usage leading to OOMs.\u00a0 Steps to reproduce are vague, but the reporter is very helpful and collected lots of data.\u00a0 Unassigned.<\/li>\n<li><a title=\"UNCONFIRMED - Major memory leak - the longer firefox is left open, the more memory it uses\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=640923\">640923<\/a>: Vague reports of increasing memory usage, lots of people have piled on.\u00a0 One useful lead:\u00a0 RSS feeds might be causing problems on Windows 7?\u00a0 The user named SineSwiper (who has alternated between being abusive and collecting useful data) thinks so.\u00a0 Unassigned. [NEEDS ANALYSIS]<\/li>\n<li><a title=\"UNCONFIRMED - Massive Memory Leak when using NoScript in Firefox 4\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=642472\">642472<\/a>: High memory usage on a mapping site.\u00a0 Very detailed steps to reproduce;\u00a0 one other user couldn&#8217;t reproduce.\u00a0 Unassigned.\u00a0 [NEEDS ANALYSIS]<\/li>\n<li><a title=\"UNCONFIRMED - Memory leak after some hours\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=643177\">643177<\/a>: Vague report.\u00a0 Unassigned.\u00a0 [CLOSE?]<\/li>\n<li><a title=\"NEW - Possible leak in the HTML5 parser\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=643940\">643940<\/a>: Ehsan found leaks in the HTML5 parser with the OS X &#8216;leaks&#8217; tool.\u00a0 Unassigned.\u00a0 [NEEDS ANALYSIS]<\/li>\n<li><a title=\"NEW - LayerManagerOGLProgram::CreateProgram leaks the vertex shader if creating the fragment shader fails\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=644073\">644073<\/a>: Ehsan found a shader leak with the OS X &#8216;leaks&#8217; tool.\u00a0 Unassigned. [NEEDS WORK]<\/li>\n<li><a title=\"UNCONFIRMED - Memory leak: closing gawker website tabs does not deallocate memory, add-ons may be involved\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=644457\">644457<\/a>: High memory usage with gawker websites and add-ons (maybe NoScript?)\u00a0 See comment 25. Unassigned.\u00a0 [CLOSE?]<\/li>\n<li><a title=\"UNCONFIRMED - Memory leak with Adblock Plus, Firebug &amp; Pagespeed enabled\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=644876\">644876<\/a>: Leak with AdBlock Plus and PageSpeed add-ons on mapcrunch.com.\u00a0 Unassigned.\u00a0 [NEEDS ANALYSIS]<\/li>\n<li><a title=\"UNCONFIRMED - Firefox 4 consumes more than 1.9 GB memory after some hours runtime (memory leak?)\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=645633\">645633<\/a>: High memory usage with somewhat detailed steps to reproduce.\u00a0 Reporter is helpful and has collected various pieces of data.\u00a0 [NEEDS ANALYSIS]<\/li>\n<li><a title=\"NEW - Creating Sandbox objects leads to memory leaks\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=646575\">646575<\/a>: Creating sandboxes causes leaks.\u00a0 Good test case.\u00a0 Unassigned.\u00a0 [NEEDS WORK]<\/li>\n<li><a title=\"NEW - A combination of several specific extensions causes memory deallocation to be delayed by 3+ minutes in firefox 4 when closing tabs\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=650350\">650350<\/a>: Problem with image element being held onto when image data has been released.\u00a0 Bz said he would look at it.\u00a0 Unassigned. [NEEDS ANALYSIS]<\/li>\n<li><a title=\"NEW - Memory leak in new profile, idle browser showing blank tab\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=650649\">650649<\/a>: with only about:blank loaded, memory usage ticks up slightly.\u00a0 Some discussion;\u00a0 it may be due to the Urlclassifier downloading things.\u00a0 If that&#8217;s true, it makes diagnosing leaks difficult. [NEEDS ANALYSIS]<\/li>\n<li><a title=\"NEW - Massive memory leak running CubicVR demo\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=651695\">651695<\/a>: Huge WebGL leak in the CubicVR demo.\u00a0 Unassigned.\u00a0 [NEEDS WORK]<\/li>\n<li><a title=\"UNCONFIRMED - js\/gc-heap memory never fully reclaimed\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=653817\">653817<\/a>: Memory increase after opening and closing tabs.\u00a0 A lot of discussion has happened, it&#8217;s unclear if the memory usage is due to legitimate things or if it&#8217;s an actual leak.\u00a0 Assigned to me.\u00a0 [NEEDS ANALYSIS]<\/li>\n<li><a title=\"UNCONFIRMED - Unreasonable memory usage on image heavy site\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=653970\">653970<\/a>: High memory usage on an image-heavy site.\u00a0 Comment 5 has a JS snippet that supposedly causes OOM crashes very quickly.\u00a0 Unassigned.\u00a0 [NEEDS ANALYSIS]<\/li>\n<li><a title=\"NEW - 70MB of collectible garbage not cleaned up\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=654028\">654028<\/a>: High memory usage on Slashdot.\u00a0 Seems to be because Slashdot runs heaps of JavaScript when you type a comment.\u00a0 Lots of discussion, seems to be due to bad GC heuristics and\/or lack of generational GC?\u00a0 Unclear if there&#8217;s an actual leak, or just delayed GC.\u00a0 Unassigned.\u00a0 [NEEDS ANALYSIS]<\/li>\n<li><a title=\"NEW - Assertion failure: m_pools.empty(), at js\/src\/assembler\/jit\/ExecutableAllocator.h:180\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=654820\">654820<\/a>: Leak in JaegerMonkey&#8217;s regular expression code generator caught by assertions.\u00a0 Assigned to cdleary.\u00a0 [NEEDS WORK]<\/li>\n<li><a title=\"NEW - Timers using small intervals (100ms or less) are never garbage collected\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=655227\">655227<\/a>: Timers using small intervals (100ms or less) are never garbage collected(!)\u00a0 Unassigned.\u00a0 [NEEDS ANALYSIS]<\/li>\n<li><a title=\"NEW - Change MaybeGC trigger\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=656120\">656120<\/a>: Bug to do GC periodically when the browser is idle.\u00a0 Assigned to Gwagner, has a patch.\u00a0 [NEEDS WORK]<\/li>\n<li><a title=\"NEW - test_prompt.html leaks until shutdown\" href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=657658\">657658<\/a>: test_prompt.html leaks.\u00a0 Unassigned.\u00a0 [NEEDS WORK]<\/li>\n<\/ul>\n<p>You can see that most bugs are marked as &#8220;[NEEDS ANALYSIS]&#8221;.\u00a0 The size of the problem and the amount of developer attention it is receiving are not in proportion.<\/p>\n<p>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.\u00a0 But the improved about:memory is a big part of that, and it won&#8217;t land until Firefox 6.\u00a0 I&#8217;m wondering if the about:memory changes should be backported to Firefox 5 in an attempt to improve our leak reports ASAP.<\/p>\n<p>Another thing I&#8217;m wondering about is being more aggressive about closing old leak reports.\u00a0 We have 624 open bugs that have the &#8220;mlk&#8221; keyword (including some recent ones that aren&#8217;t in the list above).\u00a0 The oldest of these is <a href=\"https:\/\/bugzilla.mozilla.org\/show_bug.cgi?id=39323\">bug 39323<\/a> which was filed in May 2000.\u00a0 Surely most of these aren&#8217;t relevant any more?\u00a0 It&#8217;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.\u00a0 I&#8217;d love to hear ideas about this.<\/p>\n<p>Finally, I&#8217;d like to hear if people think this blog post is useful;\u00a0 I&#8217;m happy to make it an ongoing series if so, though regular MemShrink meetings would be more effective.<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>I&#8217;ve been tracking recent memory leak reports in bug 640452. I&#8217;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&#8217;s a topic for [&hellip;]<\/p>\n","protected":false},"author":139,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4550,30,4544,4546],"tags":[],"_links":{"self":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/790"}],"collection":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/users\/139"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/comments?post=790"}],"version-history":[{"count":0,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/posts\/790\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/media?parent=790"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/categories?post=790"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mozilla.org\/nnethercote\/wp-json\/wp\/v2\/tags?post=790"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}