Firefox memory usage and memory leak news
Many Mozilla community members, including both volunteers and Mozilla Corporation employees, have been helping to reduce Firefox's memory usage and fix memory leak bugs lately. Hopefully, the result of this effort will be that Firefox 3 uses less memory than Firefox 2 did, especially after it has been used for several hours.
Memory usage
Federico Mena-Quintero submitted a patch to make Firefox discard decompressed image data after five seconds (bug 296818). ImageLib module owner Stuart Parmenter experimented with a competing idea in bug 386377, but now he plans to help with Federico's patch. The patch will make image data join text runs in using time-based caching rather than traditional space-bounded caching.
Aaron suggested having an "about:memory" page showing a breakdown of Firefox's memory use (bug 392351). When I pointed out the bug to Brendan Eich, he excitedly assigned the bug to himself.
Eli Friedman discovered that nsFloatCache was no longer necessary and eliminated most of it (bug 381385).
Memory leaks
David Baron checked in a patch for the last bug that contributed to RLk on Linux, bringing the number of XPCOM objects leaked during this test to zero. Since this test runs on Tinderbox, it's likely that regressions will be noticed quickly, even if they don't turn Tinderbox orange.
Robert Sayre created a script to load random pages and see whether they cause leaks. The random URLs come from the Yahoo directory (biased toward older, top-level pages), del.icio.us (biased toward newer, geeky pages), and AltaVista (biased toward pornography). The script detects leaks using trace-refcnt, the same test used by RL; future versions might use trace-malloc in order to catch additional leaks. Robert has caught at least 6 distinct leak bugs using this script, 3 of which have already been fixed. See LeakingPages and bug 394517 for details.
David Baron created a series of patches to the cycle collector to aid in debugging leaks. With this code, DEBUG_CC builds of Firefox can notice when an object "expected to be garbage" is not collected and then explain in detail why it was not collected.
Steve England tested the top 500 web sites, finding two leaks. Later, he tested the top 20 Firefox extensions and found leaks in several of them.
David Baron recorded seven leak debugging screencasts, which you can watch to see how David Baron debugs real leaks.
Kris Zyp found a leak in the JavaScript Engine when using the watch method (bug 394709). Igor Bukanov responded quickly with not only a patch for the bug but also a leak detection patch to enable regression testing of JavaScript Engine leaks. I asked him to modify his patch so I could use jsfunfuzz to test for JavaScript Engine leaks, and he did. (This led me to find several bugs in evalcx, but no additional leaks.)
David Baron got the stack walking code and the stack fixer working on Mac, making it possible to use trace-malloc and the refcount balancer on Mac (bug 336517, bug 392118).
How to help
You don't have to be a C++ programmer to help find leaks in Firefox.
If you're a Firefox user, an easy way to help is to browse with a trunk nightly build wrapped in a script that calls leak-gauge.pl when Firefox exits. If it reports that documents or windows leaked, try to figure out how to reproduce the leak and then file a bug report.
If you're an advanced user, you can do something similar with with trace-refcnt, which detects leaks of all reference-counted objects, not just windows and documents. Build Firefox with the .mozconfig option "--enable-logrefcnt" (or build debug) and run your build with XPCOM_MEM_LEAK_LOG=2. When Firefox exits, it will print a detailed but understandable summary of what types of objects leaked.
If you're are a C++ programmer and want to help diagnose or fix bugs, check out Performance:Leak_Tools along with David Baron's screencasts, and hang out in #developers on irc.mozilla.org.
September 22nd, 2007 at 5:57 am
[…] Adresindeki habere göre firefox kullanan fakat aşırı hafıza tüketiminden ÅŸikayetçi olan (örneÄŸin ben) kullanıcılar firefox 3 ün çıkmasıyla bu sorunundan kurtulacak.Yeni sürümün testleri hızla devam etmekte hazırlanan bir scriptle rastgele sayfalar ziyaret edilmekte ve hafıza taÅŸması oluÅŸturanlar ve buna sebep olan bug lar tespit edilmekte bu adrestetaÅŸmaya neden olan sayfaları görebilir.EÄŸer sizde firefox un geliÅŸimine yardım etmek istiyorsanız ÅŸu adresi ziyaret edip nasıl yapabileceÄŸinizi öğrenebilirsiniz.. […]
September 22nd, 2007 at 6:36 am
More information. I’ve recently purchased a second box. Running nightlies on my main home computer is a PITA. Anyway this second box has Perl installed. All I’d like is a little step-by-step help and hopefully I can help solve the scourge that is FX memory issues.
September 22nd, 2007 at 6:36 am
Oh yeah, it’s a Windows XP box.
September 22nd, 2007 at 11:56 am
pd, if you have Bash, you can use the script that Arthur pasted earlier. If you don’t, you should be able to make a similar DOS script (.bat file) using “set” instead of “export”. IIRC, with “set” you use a space instead of an equals sign.
Clement, enabling the logging used by leak-gauge.pl should not slow down Firefox much, since it only logs information about certain “large” objects (windows, documents, docshells).
September 22nd, 2007 at 3:55 pm
[…] » noticia original […]
September 23rd, 2007 at 1:45 am
Start, Run, notepad, Enter
SET NSPR_LOG_MODULES DOMLeak:5,DocumentLeak:5,nsDocShellLeak:5
SET NSPR_LOG_FILE nspr_leaks.log
firefox/firefox
perl leak-gauge.pl nspr_leaks.log
Save As tstMemLeaks.bat
C:\Perl>tstMemLeaks.bat
C:\Perl>SET NSPR_LOG_MODULES DOMLeak:5,DocumentLeak:5,nsDocShellLeak:5
Environment variable NSPR_LOG_MODULES not defined
C:\Perl>SET NSPR_LOG_FILE nspr_leaks.log
Environment variable NSPR_LOG_FILE not defined
C:\Perl>firefox/firefox
‘firefox’ is not recognized as an internal or external command,
operable program or batch file.
C:\Perl>perl leak-gauge.pl nspr_leaks.log
Can’t open perl script “leak-gauge.pl”: No such file or directory
September 23rd, 2007 at 1:52 am
I was wrong about the “set” syntax; you do need the equals signs. If there’s a difference between the bash “export” syntax and the DOS “set” syntax it involves how they handle quotes and spaces.
You’ll have to replace “firefox/firefox” with the path to your firefox.exe, of course. You can download leak-gauge.pl using the link in the post.
September 23rd, 2007 at 3:44 am
Woohooo it’s happening!
September 24th, 2007 at 10:07 am
Re http://wiki.mozilla.org/LeakingPages
Dunno if this might be helpful, or give you somewhere else to look, but for what it’s worth:
Some of these pages also trigger a Windows resource leakage bug that goes all the way back to core Mosaic code, so is seen in various builds of pre-Moz Netscape and IE as well.
The principle trigger for that bug is visible active objects inside another structure, usually meaning either links with a lot of visible text or flash embeds, inside a table cell. I’m guessing CSS’s substitution for table cells has the same effect.
In an offending page of yesteryear, I was able to get rid of the leak-effect simply by shortening the *visible* text in links that were inside table cells.
The problem as described in Firefox sounds so similar, and is tickled by such similar pages, I can’t help thinking there’s some common factor here.
September 24th, 2007 at 10:33 am
I can only hope that the common memory leaks, that are straightforward to fix, are backported to the Firefox 1.5 and 2.0 series. This is important for Enterprise distributions where application upgrades are often not tolerated.
I know that this is something that the Linux vendors can do, but it would make more sense if this effort was made under the Mozilla umbrella than done by individual vendors.
September 24th, 2007 at 10:56 am
pd, could you post your “working” version of the .bat file?
Save some of us lazy people some time :)
(Windows 2K and XP also have a more advanced shell:
.bat -> command.com — legacy/compatability
.cmd -> cmd.exe )
September 24th, 2007 at 11:55 am
I still don’t understand why loading a 2 mb xml file in firefox needs to use 170 megs of ram.. I’m sure there can be more efficient algorthims to add +s and -ses to the tree.
September 24th, 2007 at 12:10 pm
I am concerned about the next javascript engine, Tamarin using a conservative garbage collector (MMgc) instead of a precise one. It could have a lot of false positives with compressed image data and retain more memory.
September 24th, 2007 at 1:11 pm
(Windows 2K and XP also have a more advanced shell:
.bat -> command.com — legacy/compatability
.cmd -> cmd.exe )
hahahahaha yeah right
did you ever use the bash or tcsh shells?
you stupid fool!
September 24th, 2007 at 2:29 pm
[…] Mozilla community members, including both volunteers and Mozilla Corporation employees, have been helping to reduce Firefox’s memory usage and fix memory leak bugs […]
September 24th, 2007 at 3:56 pm
This is greaaaat news, I think that performance(processing and memory usage) is the ONLY firefox drawback currently, with improved performance users will have no excuse for using other browsers.
September 24th, 2007 at 5:29 pm
[…] Mozilla community members, including both volunteers and Mozilla Corporation employees, have been helping to reduce Firefox’s memory usage and fix memory leak bugs lately. Hopefully, the result of this effort will be that Firefox 3 uses […]
September 24th, 2007 at 6:20 pm
This is on Slashdot, too: http://slashdot.org/article.pl?sid=07/09/24/1521240
September 24th, 2007 at 6:59 pm
My Ubuntu Feisty Firefox always crash when I open up few chat screen with meebo. Weird!
September 24th, 2007 at 9:59 pm
“(Windows 2K and XP also have a more advanced shell:
.bat -> command.com — legacy/compatability
.cmd -> cmd.exe )”
“hahahahaha yeah right
did you ever use the bash or tcsh shells?
you stupid fool!”
Errm… How about Windows PowerShell?
September 24th, 2007 at 10:27 pm
[…] Jesse Ruderman » Firefox memory usage and memory leak news good to see the Mozilla folks focusing on performance. Firefox has taken a nosedive for me in performance terms of late, though it seems probable that that’s extension related. (tags: mozilla firefox memoryleaks performance via:#redmonk) […]
September 25th, 2007 at 1:08 am
Doesn’t some huge memory usages come from some leaky addons?
September 25th, 2007 at 4:13 am
[…] bueno, al parecer ya lo están arreglando Posted by Carlos Filed in Noticias, TecnologÃa Tags: Browsers, […]
September 25th, 2007 at 10:43 am
You say that people could use a script. Like what script? Maybe like the script in https://bugzilla.mozilla.org/show_bug.cgi?id=390971….
Well, it might need to get reviewed first.
September 25th, 2007 at 11:18 am
[…] Vientos. […]
September 25th, 2007 at 1:18 pm
[…] in Firefox 2.0) hasn’t gone unnoticed by the fine folks of the Mozilla community. In fact, they’ve been going memory leak crazy. That’s good news, especially for users of older Macs with older versions of the OS as Firefox […]
September 25th, 2007 at 10:06 pm
[…] notará cuando llevemos unas horas navegando con él. Además cualquiera puede contribuir enviando ciertos datos (inglés) sobre el comportamiento de su Firefox […]
September 25th, 2007 at 10:15 pm
[…] Desarrolladores de Firefox están trabajando para que la versión 3 del navegador consuma menos memoria. […]
September 26th, 2007 at 12:13 am
[…] SquareFree (vÃa […]
September 26th, 2007 at 2:21 pm
[…] segnalare memory leak si può fare riferimento a questo blog. Per segnalare i memory leak, vi consiglio di installare l’estensione Leak Monitor che ha il […]
September 27th, 2007 at 6:30 am
[…] i ranghi dei volontari che tra quelli degli impiegati della Corporation, stanno lavorando sodo per ridurre il consumo di memoria di Firefox e correggere i memory leak che hanno contraddistinto le incarnazioni più recenti della volpe di […]
September 28th, 2007 at 4:15 am
[…] Firefox Memory Leak News […]
October 2nd, 2007 at 5:41 am
[…] its success. For footprint and memory use in particular there is some great work that was recently announced and everyone should read about it at. I guess that was a pretty long winded answer to the memory […]