Firefox memory leak progress
Update 2007-11-06: see also my more recent post on this topic, Firefox memory usage and memory leak news, from September 2007.
One of the more common complaints about Firefox 1.5 was that it leaked a lot of memory. I don't know how often these leaks were severe enough to cause noticeable slowdowns or thrashing, but enough Firefox users seem to care about memory leaks that I thought I'd post something about what we've done and what we're doing.
Two memory leak bugs were fixed in Firefox 1.5.0.1, released earlier this week:
- 316775 - Leak when selecting.
- 317478 - Leaks due to global scope polluter being removed from not enough (?) prototype chains.
In addition, the following memory leaks have been fixed on the trunk since the branch point for Firefox 1.5:
- 241518 - Calling addEventListener with a closure holding a content node leaks the document. (Many Greasemonkey scripts use addEventListener, and they each live within implied closures. Otherwise, this leak pattern isn't too common, mostly because Internet Explorer 6 leaks under the same circumstances.)
- 321283 - Using Find causes documents to leak.
- 315708 - Should release found link and current window object from nsTypeAheadFind.cpp.
- 315951 - Unknown content type dialog leaks domwindow.
- 319123 - Leak with contentsink-parser-dtd cycle involving document.write().
- 323441 - Memory leak if a site sets location and then document.writes (e.g. when visiting www.economist.com).
- 323377 - Lots of leaks in nsInternetSearchService.
- 323532 - Leak when using history autocomplete.
- 315427 - Bad nullcheck in nsXULPrototypeElement::ReleaseSubtree, causing the Options window to leak if the remembered panel is the cache panel.
- 323534 - CreateTreeWalker can cause leaks due to cycles created by closures.
The trunk seems close to not leaking huge object graphs during my typical browsing sessions (YMMV). The only big leak I still see all the time is a leak at Gmail. The leak might be related to the "unused XMLHttpRequest" leak that David Baron is working on, or it might not -- when I asked whether Gmail is considering working around the "unused XMLHttpRequest" leak bug, a Gmail coder said he didn't think Gmail created any XMLHttpRequest objects it didn't use.
David Baron's leak-gauge has been allowing more people to test for large memory leaks with their own browsing habits, extensions, and favorite sites. At least 19 people filed 30 memory leak bug reports found using leak-gauge, accounting for more than half of the memory leak bug reports (and most of the memory leak bug reporters) since its introduction. The bug reports look pretty useful, and are definitely more useful than general complaints about high memory usage after using Firefox for a few hours.
If you're still suffering a lot from memory leaks in Firefox 1.5.0.1 and/or want to help find memory leak bugs, head over to The Burning Edge and try out a trunk build. If you prefer to stick with stable versions of Firefox, don't worry -- many of the fixes that are currently only on the trunk will be included in the next scheduled update (currently planned to be called Firefox 1.5.0.2 and released in March), most of them will be included in Firefox 2, and all of them will be included in Firefox 3.
Leaks in extensions
Recognizing that memory leaks aren't always due to bugs in Firefox itself, Steve England and others have tested popular Firefox extensions for memory leaks. They found that Session saver, NoScript, IE Tab, and the combination of FlashGot and Filterset.G Updater cause leaks.
Giorgio Maone, the author of NoScript and FlashGot, has already fixed the biggest leak in NoScript thanks to Steve's bug report. He is now working on threading issues in FlashGot that prevent debugging and might be responsible for the leaks. Authors of the other extensions haven't been as fast to fix their leaks.
I also fixed several minor memory leaks in my own extensions recently, some found through code inspection and some found using leak-gauge. Search Keys 0.7.2 and below kept parts of search result pages alive for the lifetime of the window due to an unintentionally global variable (a missing "var"). Thumbs 0.6.1 and below kept the DOMWindow for the page Thumbs was last used on alive until shutdown.
Other causes of high memory usage
Memory leaks aren't the only thing that can cause Firefox to (appear to) use a lot of memory. See MozillaZine Fourms: Memory usage FQA and MozillaZine KB: Reducing memory usage.
February 4th, 2006 at 2:31 am
This is great to hear. IMO Firefox 1.5 was a poorly-conceived release. The latest 0.1 increment does nothing to fix the issues. I can confirm that almost every trunk release I’m tested this year perfoms much better. I use them (this is from about a week ago) every day for my general browsing and I have another slightly older one open at this moment for my work-related stuff. I just kept one of these open for about four days and memory usage didn’t creep nearly as high as what I’m used to – most importatly I observed memory use decreasing as I closed tabs. This is on Windows XP. As I said, great to hear.
February 4th, 2006 at 2:34 am
Awesome, thanks for the progress update!
FYI, both links at the bottom point to the mozillaZine forum thread, while the latter one should point to <snip>
February 4th, 2006 at 2:40 am
Link fixed, thanks.
February 4th, 2006 at 8:06 am
What methods can I use to test my own extensions for memory leaks? Is the leak-gauge deal what I need? Or are there other strategies?
February 4th, 2006 at 8:18 am
I’m with Jonah. I would love a guide or someway to test my extension for memory leaks. I really don’t know where to begin.
February 4th, 2006 at 10:54 am
Is nspr.log supposed to be logged to in 1.5.0.1 stable? I tried setting the environment variables and nspr.log is produced, but it is always 0 bytes.
February 4th, 2006 at 11:37 am
Thanks for a very informative post.
I think it’s important that regular users can see that their concerns about memory use are being addressed, (even if users who follow bug reports already know that).
What is the policy about filing bugs for leaky extensions?
I confirmed one that had already been filed, but was under the impression that problems should be reported directly to the extension developer.
Is there any word on whether leak-testing will be enabled on branch builds?
February 4th, 2006 at 1:52 pm
Jesse, did you mean the 1.6a trunk, not 1.5.x?
February 4th, 2006 at 2:19 pm
At last. I started using Firefox even before it was “Firefox” (0.7 or so). I followed the development pretty close (compared to a joe q public) and was pretty much appalled to the mentality developers had (that was the impression I got); ‘this or that problem/bug isn’t going to affect large enough userbase, so we’ll fix it at a some later version, if ever’. That bundled to the facts I was hit with the huge memory usage bugs too and Opera making its browser free w/o ads made me change to Opera.
Funnily enough, I was hit with memory usage bugs and crashing in Opera too, but those look like they’re all gone since updating to latest flash, quicktime etc plugins.
February 4th, 2006 at 6:22 pm
The logging code that is used for detecting memory leaks is only on the trunk for now. It might be included in Firefox 1.5.0.2. You could build Firefox 1.5.0.1 yourself with the logging patch in bug 320192, but I don’t see the point in doing that now — it’s known to leak a lot (see the “fixed on trunk” list) so it would be difficult to isolate other leaks.
February 4th, 2006 at 6:23 pm
djet, the builds labeled 1.6a1 come from the trunk, while the builds labeled 1.5.0.1 come from a branch.
February 4th, 2006 at 6:27 pm
Krane, “this or that problem/bug isn’t going to affect large enough userbase, so we’ll fix it at a some later version, if ever” is not a “mentality” to be “appalled” at. It’s something that any sane development team will say for some bugs. Maybe we were wrong in a few cases about the impact of a bug, or maybe we set the bar too high sometimes, and those are more legitimate things to complain about.
February 4th, 2006 at 6:30 pm
Flummox asked,
The general policy is that bugs in extensions shouldn’t be in bugzilla.mozilla.org, but since memory leaks in popular extensions affect the perception of Firefox’s quality and extension developers often need help in fixing them, it’s useful to track them all in one place. If you file a bug about an extension in bugzilla.mozilla.org, be sure to tell the extension developer too.
February 5th, 2006 at 12:11 am
Interesting info, thanks. I’ve used the last several versions of FF, for maybe 18+ months I would guess. I love thr browser. But anecdotal evidence has me thinking that the RAM and CPU problems have gotten worse instead of better.
But the article brings up a great point, how much if any of the problems are the responsibility of extensions?
February 5th, 2006 at 12:21 am
Well for me, it’s not just the memory usage that’s crap, CPU usage jumps to > 15% after more than 15 minutes use or so, like a “CPU leak” or something.
No idea why, but that’s why I use Opera for most of my browsing I suppose.
February 5th, 2006 at 6:46 am
[…] è¿™ç¯‡æ–‡ç« ï¼ˆä½œè€…æ˜¯å¼€å‘者）解释了目å‰è¿™ä¸ªé—®é¢˜çš„进展，首先是å¯ä»¥ç”¨æœ€æ–°ç‰ˆï¼Œç¨³å®šç‰ˆæ˜¯1.5.0.1，刚出的，它比1.5ä¿®å¤äº†ä¸¤ä¸ªæ³„露的地方；其次是如果想进一æ¥ç ”究，å¯ä»¥ç”¨ä¸€äº›å·¥å…·æ¥ï¼ˆPerlå’ŒJavascript的）分æžlog文件，从而获å–是哪些东西泄露了。 […]
February 5th, 2006 at 9:27 am
I’ve been using Firefox since before 1.0 and it has been improving at each step of the way (Anyone remember trying to uses pages that had java back then). The best thing is, I didn’t have to code it. I got it for free even though someone else put in the long hours to create it. I would love for firefox to use less memory and have fewer memory leaks, but so far, I still like it better than IE and Opera. Regardless, I suggest not getting apalled at free open sources software. If you like it, use it. If you don’t like it, don’t use it. It’s not worth the stress to get upset over software that we don’t have to use.
February 5th, 2006 at 5:24 pm
Perhaps someone could add some documentation for the memory leak tool to devmo and link to it from the extensions section. That might help spread the message and let authors know how to check their extensions.
February 5th, 2006 at 10:20 pm
From some limited using during the last days I must say the 1.5.0.1 update improved the situation quite a bit for me. Firefox now stays around the 300MB limit I’ve set in user.js. :)
(Memory usage with 27 tabs: 199384K Mem / 188248K VM Mem)
Like other’s have posted, I’ve tried Opera too now that it’s free. While it does consume considerably less memory it still can’t replace Firefox for me. It lacks the customizability extentions give, it’s quite cluttered imho also I’m just used to using Firefox since I’ve been using it since the first version came out in the Phoenix days.
February 5th, 2006 at 10:25 pm
This was on Digg:
http://digg.com/software/Firefox_Memory_Leak_Progress
February 6th, 2006 at 7:38 am
Even with this image preloading greasemonkey extension, I have no problems at all with memory leaks. I do close firefox when I don’t use it though.
http://worshiptheglitch.com/2005/09/greasemonkey-script-quickgallery.html
February 6th, 2006 at 8:00 am
Some plugins leak too. Firefox gets the blame for these too, and the usual diagnostic methods (safe mode, new profile, deleting profile files) do not remove plugins.
February 6th, 2006 at 7:13 pm
My Firefox does have a leak, probably with Session saver. With session saver, it makes sense to close Firefox, but I always forget to close it.
February 7th, 2006 at 10:09 am
There is -safe-mode for debugging as we know, but this type of debugging is very limited. I have problem with some plugin, i dont know which one (from a long time), but will not remove all my extensions just to test it… i have around ~20 installed and it will be nightmare to test them !!!
Much better will be if we have the ability to disable (not deinstall them) installed extensions one by one (with a simple check box or something). This will ease alot not only memory leaks testing but testing extensions in general.
I puposed such addtion in bugzilla, but no comments on it :(.
February 8th, 2006 at 9:53 am
I’m interested in how much these leaks represent in memory terms. If an extension leaks a small ammount of memory on every new window or something, then that’s rather triffling..
February 8th, 2006 at 12:43 pm
As has been mentioned check out this http://ddhr.org/2006/01/11/firefox-memory-leak/
Worked great for me. Basically get a new tab, type “about:config” add a new boolean value named “config.trim_on_minimize” and set it to true.
Great work.
February 8th, 2006 at 2:40 pm
[…] Memory leak progress […]
February 10th, 2006 at 9:48 pm
[…] One example of this is Gecko code bloat. While we’re getting faster, cleaner and better overall. While we solved many issues and created Firefox that unbloated the Gecko Browser thing, we’re still far away from solving this problem. Jesse Ruderman recently blogged about progress in fixing Firefox 1.5 leaks that seems to be more affecting user than Firefox 1.0 ones! […]
February 12th, 2006 at 12:32 pm
Jesse, thanks for taking this issue on. I am a well-experienced developer and I know how tough memory leaks can be to deal with, but it is important for FF that this issue doesn’t get in the way of its adoption. There are corporations now that are beginning to actively embrace FF – I’d hate to see the momentum lost. In my opinion, the memory leak issue should continue to be a number one priority of the FF team right now.
February 13th, 2006 at 8:57 pm
(Windows XP Pro on AMD64) I used to get regular crashes with 1.0; and everytime a new upgrade became available, the browser window would not open from any icon, although the program would be running in the Task Manager. But with 1.5.0.1, I haven’t noticed any problems running FF. I have eleven running extensions and no noticeable problems of memory. Updating regularly is working for me. But I don’t use Shockwave or Adobe Acrobat Reader. Flashblock keeps the Flash ads at bay when I don’t want them. Tried the new free Opera, and it is nice, but Firefox does have more adjustability for me. Internet Explorer can die the death, for all I care. I’m using Firefox on Windows, Linux, and even MacOS (where Safari is an impressive browser). I want to thank the Mozilla community for all their work on FF, and I hope their “market share” jumps to 50% by this time next year. (Thunderbird is an awesome e-mail client too. Thanks, guys.)
February 14th, 2006 at 2:46 am
I have a question. I play games online suck as warcraft 3 The Frozen Throne and Final Fantasy 11 and I’ve noticed major major slow downs. Slow downs are so bad both games are unplayable when opened but when I alt tab my CPU Mem is maxed at 100% then goes down as the games are in the background and task manager is on top then when I pull the game back up all is well for 40secs then the lag starts again.
I’ve done a speed test on my modem and contacted my ISP and the net is fine. I’ve done a full system reformat and defrag but I never liked IE so I downloaded FireFox 1.5.0 asap then did all my window updates … sadly the lag is still there. Is FireFox causing this I’m just sooo lost. I’ve done numerous Maleware, spyware scans and registry cleans but still I just dont get it. Before I had no lag whatsoever but about 3 weeks ago I clicked the update link on FireFox and I didnt realize that it could be the problem until someone mentioned that FF 1.5.0 had mem leaks. Can someone please help me out thank you in advanced.
February 14th, 2006 at 7:40 pm
Menu X causes a big leak in combo with Groowe and/or Clusty.
February 17th, 2006 at 6:28 pm
[…] So, minimizing the amount of memory that Firefox uses is obviously something I’d be interested in. A Wired.com “monkey bite” led me to this mozillazine entry discussing (both real and not) “memory leaks” in the application. That, in turn, led me to a more useful article by Jesse Ruderman (who I gather is a contributor to Mozilla) on memory leak progress in Firefox (and the trunk builds). Of course, Jesse’s entry itself led me to a detection tool for leaks as well as a general memory usage info thread and reducing memory usage information. […]
February 27th, 2006 at 11:15 am
[quote]Menu X causes a big leak in combo with Groowe and/or Clusty.[/quote]
Not for me. Tested with leak-gauge.pl and no reported leaks with all three extensions installed.
February 27th, 2006 at 6:11 pm
[…] En las últimas versiones los ingenieros del proyecto han trabajado duro para eliminar todas esas “fugas” de memoria (los famosos memory leaks) reportadas pero todavÃa queda un largo camino. […]
March 3rd, 2006 at 2:30 am
[…] 内å˜æ³„æ¼å‚è€ƒè¿™ä¸¤ç¯‡æ–‡ç« http://www.squarefree.com/2006/02/04/memory-leak-progress/ http://www.squarefree.com/2006/01/13/memory-leak-detection-tool/ […]
March 3rd, 2006 at 2:34 am
[…] è¿™ç¯‡æ–‡ç« ï¼ˆä½œè€…æ˜¯å¼€å‘者）解释了目å‰è¿™ä¸ªé—®é¢˜çš„进展，首先是å¯ä»¥ç”¨æœ€æ–°ç‰ˆï¼Œç¨³å®šç‰ˆæ˜¯1.5.0.1，刚出的，它比1.5ä¿®å¤äº†ä¸¤ä¸ªæ³„露的地方；其次是如果想进一æ¥ç ”究，å¯ä»¥ç”¨ä¸€äº›å·¥å…·æ¥ï¼ˆPerlå’ŒJavascript的）分æžlog文件，从而获å–是哪些东西泄露了。 […]