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:

32 Responses to “Firefox memory leak detection tool”

  1. Thomas Stache Says:

    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.

  2. kbglob Says:

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

    ……

  3. Martijn Says:

    So is dbaron going to (try to) fix all the memory leaks I would find? ;)

  4. Ian Says:

    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.

  5. Ian Says:

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

  6. BeLeBored Says:

    Install Perl in windows to track memory leaks?? Uh. no. Great concept generally though :)

  7. Martijn Says:

    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.

  8. CooLynX Says:

    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.

  9. Martijn Says:

    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

  10. Steve Chapel Says:

    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.

  11. Jesse Ruderman Says:

    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.

  12. Randy Bolton Says:

    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.

  13. Manoj Mehta Says:

    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

  14. Jesse Ruderman Says:

    Manoj: Yes, I’ve seen those leaks at Gmail. See https://bugzilla.mozilla.org/show_bug.cgi?id=321282.

  15. SuperMichael Says:

    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.

  16. Jesse Ruderman Says:

    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.

  17. Manoj Mehta Says:

    The search continues…

  18. SuperMichael Says:

    I hope it doesn’t sound rude but I hope that there’ll be a fix for that bug in the near future.

  19. VanillaMozilla Says:

    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?

  20. pd Says:

    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.

  21. Jesse Ruderman Says:

    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.

    Where are the clear graphical help pages on how to set the variables?

    I thought that was clear enough.

    Where is an address to upload a log file to?

    We don’t need log files as much as we need steps to reproduce leaks. Report bugs at https://bugzilla.mozilla.org/.

    Which build numbers and dates actually support this logging?

    I don’t remember the exact day, but 2006-01-07 and later trunk builds have it.

    Where is a path to the executable from which I can install a compatible build?

    http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

  22. SuperMichael Says:

    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

  23. Jesse Ruderman Says:

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

  24. VanillaMozilla Says:

    Thanks, Jesse. I forgot to start from the command line. It works now.

  25. MTCMonkey Says:

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

  26. Erikstotle » Sick of Firefox’s Memory Leaks? Help Fix it! Says:

    [...] read more | digg story Posted by Erikstotle | [...]

  27. meneame.net Says:

    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.”…

  28. creeront Says:

    Why does purify not work for the developers of firefox?

  29. Jesse Ruderman Says:

    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 :)

  30. Jacob Klein Says:

    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

  31. Jacob Klein Says:

    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

  32. Matt Nordhoff Says:

    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.