Firefox memory leak detection tool
David Baron recently wrote a tool that testers can use to help reduce memory leaks in Firefox. With this tool, you can find out what leaks you encounter during your normal browsing patterns and report useful bugs when you encounter leaks.
It detects many large leaks even though it only tracks three types of objects (documents, docshells, and domwindows) because many large leaks entrain at least one of those objects. It tries to report the URLs associated with the leaks it detects, allowing you to go back and figure out the steps needed to reproduce the bug.
I have found three leaks so far with this tool. David Baron has already fixed one of them on the trunk.
To use leak-gauge.pl, you need a version of Firefox with the logging code, such as a recent trunk nightly build. If you're using Windows, you'll also need to download Perl. leak-gauge.pl contains instructions for making Firefox log the required information and for running leak-gauge.pl to analyze the log.
Update 2006-01-14: There's also a JavaScript version, which might be easier to use if you use Windows and don't have Perl.
Further reading:
- David Baron: How to file useful leak bugs
- David Baron: How to debug leaks
- David Baron: Using XPCOM in JavaScript without leaking
- Bug 320192, where leak-gauge.pl was introduced and where the associated patches lived.
- Bug 323075, which lists David Baron's ideas for an extension that would monitor JavaScript memory use.
January 13th, 2006 at 4:44 am
I’m glad to see that David works so hard on reducing Geckos memory footprint. I regularly restart Firefox to free memory, after it has allocated up to 300MB of RAM (not sure if this includes virtual memory) due to heavy tab usage (open new tab from feed reader, read page, close tab). Sometimes Firefox’ performance slows down to a crawl. I hope it will improve soon.
January 13th, 2006 at 5:24 am
Herramienta para detectar problemas de memoria en Firefoz…
Jesse Ruderman de Mozilla tiene un post de una herramienta para detectar los famosos memory leaks (alguien traduzca eso a algo que no de asco) en Firefox.
Sirve tanto para Windows como para Linux (aguante perl).
……
January 13th, 2006 at 6:07 am
So is dbaron going to (try to) fix all the memory leaks I would find? ;)
January 13th, 2006 at 6:08 am
It would be nice if any leak fixes which are trivial/have a large impact could be considered for inclusion into the Firefox 1.5.0.* updates and also the 1.8.1 branch.
January 13th, 2006 at 7:10 am
Oh, and if you want leaks, go to EUObserver.com with JavaScript turned on, (and for best effect, open up lots of tabs at once on that site).
January 13th, 2006 at 12:22 pm
Install Perl in windows to track memory leaks?? Uh. no. Great concept generally though :)
January 13th, 2006 at 2:11 pm
I’ve made a batch file that does all the things automatically
http://www.wargers.org/mozilla/run_with_nspr.bat
Just put it in the Firefox directory, put leak-gauge.pl in C:\mozilla\ and then run it. Then, after you’ve closed Firefox, you can see 2 files:
nspr.log – the actual log file
nspr_leaks.log – the file where you can see if you had any leaks during the session.
You still need to have perl installed, though.
January 13th, 2006 at 2:43 pm
Maybe it is time to think about making an .exe or similar “leak catcher” for windows users? Like that great idea about javascript extension. That would greatly increase user feedback. I think Talkback is a good example.
I doubt there will be many users who want to install this “huge thing” called Perl just to run this small script and track the memory leaks. :P
Those who has memory leaks does not know how to use such scripts but those who know how to use them does not have memory leaks. And again – we speak in different language even if it is english. ;)
Some kind of “lamer friendly” extension would be much better. People are lazy or too busy. Most of us would like to help to improve Firefox but do not have time to read all those docs. Maybe you should announce some kind of contest or whatever, to create simple but useful tool. It will help in future, too.
January 13th, 2006 at 5:16 pm
David Baron just made the html+js version of his script:
http://lxr.mozilla.org/mozilla/source/tools/footprint/leak-gauge.html
The file is not there yet in lxr, as I speak, but it should be there tomorrow.
You can see the file already here in bonsai:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/tools/footprint/leak-gauge.html&rev=1.3&root=/cvsroot
January 13th, 2006 at 9:11 pm
Ian said “Oh, and if you want leaks, go to EUObserver.com with JavaScript turned on, (and for best effect, open up lots of tabs at once on that site).”
I did just that. I opened ten different tabs on that site with JavaScript on and did some naviagtion in each tab. Result: 0 leaks. My advice is to try the tool yourself instead of blindly guessing where the leaks occur — that’s the whole purpose of the tool.
January 13th, 2006 at 9:42 pm
To be fair to Ian, the tool doesn’t detect all leaks — it only detects leaks that entrain domwindows, documents, or docshells. Also, Ian is probably using Firefox 1.5.0.x, which doesn’t have a fix for bug 241518.
January 15th, 2006 at 2:40 pm
All of this is really nice – if you are a computer programer. How about an executable for those of us who don’t program computers, have never written anything with,for, or in Java — and really don’t want to destroy their computer by writting code when they really don’t know what they are doing.
January 15th, 2006 at 4:42 pm
I found some leaks using the script when reading my email using gmail. Just logging into gmail causes outer and inner windows to leak. Have you seen these leaks Jesse?
Leaked outer window 225c408 at address 225c408.
Leaked outer window 2780c38 at address 2780c38.
Leaked inner window 119a478 (outer 2780c38) at address 119a478.
… with URI “http://mail.google.com/mail/html/loading.html”.
Leaked inner window 273f398 (outer 2780c38) at address 273f398.
… with URI “http://mail.google.com/mail/?view=page&name=js&ver=c0d89211112a7d0e”.
Leaked outer window 3d8fe48 at address 3d8fe48.
Leaked inner window 3d7a1f8 (outer 3d8fe48) at address 3d7a1f8.
… with URI “http://mail.google.com/mail/html/loading.html”.
Leaked inner window 400eca8 (outer 3d8fe48) at address 400eca8.
… with URI “http://mail.google.com/mail/?&ik=d26d079788&view=tl&search=inbox&start=0&tlt=108d05f4b8f&fp=645ff489fb8d88b9&auto=1&zx=w3hshg-hewhyk”.
Summary:
Leaked 7 out of 108 DOM Windows
Leaked 0 out of 120 documents
Leaked 0 out of 33 docshells
January 15th, 2006 at 4:48 pm
Manoj: Yes, I’ve seen those leaks at Gmail. See https://bugzilla.mozilla.org/show_bug.cgi?id=321282.
January 16th, 2006 at 12:26 am
Jesse do you think it would be possible to include the memory leak code in the branch nightlies.
I’m really intrested in running it but I’m a bit worried about the possible unstableness or breakage of the trunk nightlies.
January 16th, 2006 at 12:57 am
IIRC, David Baron said he didn’t want to put the logging code on the branch unless/until the branch had a fix for bug 241518. I don’t remember where he said that.
January 17th, 2006 at 1:08 pm
The search continues…
January 17th, 2006 at 2:58 pm
I hope it doesn’t sound rude but I hope that there’ll be a fix for that bug in the near future.
January 18th, 2006 at 2:08 pm
I can’t get the JavaScript tool to work. I saved it as leak-test.html and set the environmental variables. Then I opened the file with the latest nightly build and a new profile, and started surfing. No log file was created. I also tried surfing without opening the leak-test file. Still no log file was created. JavaScript was enabled. Am I doing something wrong?
January 19th, 2006 at 4:08 am
The instructions are pathetic.
For the army of amatuers out there who could be running these tests and hopefully solving a lot of memory leaks that currently plague Firefox, there must be better doco and an easier to use tool.
Where are the clear graphical help pages on how to set the variables?
Where is an address to upload a log file to?
Which build numbers and dates actually support this logging?
Where is a path to the executable from which I can install a compatible build?
Sorry but http://lxr.mozilla.org/mozilla/source/tools/footprint/leak-gauge.html is not good enough.
I’d really like to help but this is not a friendly tool to me and I write Perl code every day.
January 19th, 2006 at 4:39 am
I’m not sure we need an “army of amatuers” helping to find memory leak bugs. So far since the release of the tool, experienced bug reporters have been filing useful memory leak bugs slightly faster than dbaron can fix them. Maybe we’ll decide we need to include more users later, and then we’d work on making that possible.
I thought that was clear enough.
We don’t need log files as much as we need steps to reproduce leaks. Report bugs at https://bugzilla.mozilla.org/.
I don’t remember the exact day, but 2006-01-07 and later trunk builds have it.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
January 19th, 2006 at 9:34 am
Well I hope then that the more “experienced” users are able to find most of the bugs because having to restart Firefox a few times a day with 20+ open tabs is quite annoying.
Like I posted earlier I’d like to help finding bugs but I don’t want to get another tweak-burnout like I had earlier or have an unstable browser because of running the trunk nightlies.
Current Memory Usage with 38 open tabs:
Mem usage: 711120KB // VM Size: 857716KB
January 22nd, 2006 at 11:45 pm
Three more things that might not be obvious:
* This works with both debug builds and with normal builds (such as nightlies).
* You usually have to run Firefox from the same command prompt from which you set the environment variables.
* If it says “Leaked 0 out of 0 DOM Windows”, then something is wrong. One possibility is that the log file is empty, which might be the result of using an old build. (Recent trunk builds have the logging code for detecting leaks; Firefox 1.5 does not.)
January 24th, 2006 at 10:22 am
Thanks, Jesse. I forgot to start from the command line. It works now.
February 8th, 2006 at 6:23 am
From the Mouths of Babes?
I am running Win2K sp4 with latest / greatest patches and FF 1.0.7. Since this is the place for this kind of information, I thought I would post it just in case something inadvertantly is helpful.
I noticed that the behavior has been the same from version to version : firefox.exe proc seems initially to request memory and be frugle with it, then it hits some critical mass barrier and losses its mind. My common behavior on the OS: I leave my computer running for DAYZ with many tabs in each FF (and its spawed browsers). When it is running in minimized mode, it seems to keep its mind a lot better than not minimized.
Too bad there is not some kind of light weight top / traceroute / process monitor with snapshot logging at preset timed intervals – so you can simply ‘grep’ that log after trying various FF usage scenarios. (Whew! Say that ten times) If there is.. then let me konw and I will run it. I can almost force the mem leak if I want too but it takes time over night. (And I understand I would have to upgrade to 1.5.0.1.)
February 8th, 2006 at 11:12 am
[…] read more | digg story Posted by Erikstotle | […]
February 8th, 2006 at 11:16 am
Memory leak detection tool for Firefox., help to get rid of leaks!…
“David Baron recently wrote a tool that testers can use to help reduce memory leaks in Firefox. With this tool, you can find out what leaks you encounter during your normal browsing patterns and report useful bugs when you encounter leaks.”…
February 8th, 2006 at 12:17 pm
Why does purify not work for the developers of firefox?
February 8th, 2006 at 1:13 pm
creeront, Firefox developers do have more sophisticated tools than leak-gauge (I don’t know if they use purify in particular). Those tools don’t tell the developers if there’s a leak that doesn’t occur with the developer’s usage patterns / favorite sites / extensions. Those tools also don’t tell developers which leaks actually cause users the most pain, which can help prioritize leak fixing. It’s easier to get dozens of testers to use something like leak-gauge than it is to get dozens of testers to use something like purify :)
February 17th, 2006 at 12:39 am
I also created a batch (.bat) file that will work for Windows. It works under the following assumptions:
– Firefox is installed in “C:\Program Files\Mozilla Firefox”
– Perl is installed
– The perl script “leak-guage.pl” is stored in the Firefox directory
After a browsing session, it’ll bring up notepad with the leakage info. If you then wanted to save that information to somewhere else, do it, else, don’t.
Here is the batch file:
————————-
@echo off
set NSPR_LOG_MODULES=DOMLeak:5,DocumentLeak:5,nsDocShellLeak:5
set NSPR_LOG_FILE=C:/Program Files/Mozilla Firefox/nspr.log
start “Firefox” /wait “C:\Program Files\Mozilla Firefox\Firefox.exe”
type “C:\Program Files\Mozilla Firefox\nspr.log” | perl “C:\Program Files\Mozilla Firefox\leak-guage.pl” > “C:\Program Files\Mozilla Firefox\nspr_leaks.log”
start “Leaks” “C:\Windows\notepad.exe” “C:\Program Files\Mozilla Firefox\nspr_leaks.log”
@echo on
February 17th, 2006 at 12:43 am
The easiest way to make a one-click startup without seeing the “batch execution window” is to do the following:
– Create a shortcut to the .bat file
– Edit the shortcut’s properties to:
– Run: Minimized
February 23rd, 2006 at 10:07 pm
Nightly Tester Tools 0.8b1 (will that HTML work?) now supports analyzing the leak log. So you won’t need Perl or leak-guage.pl, but you still will need to start Firefox with those environment variables.
MTCMonkey: In my experience, the critical mass seems to be when the memory cache is forced to go over the limit you set. After that, Firefox will just almost stop throwing things out of the memory cache for me.