Mopping Up Mozilla Memory Leaks

mouseman writes "Geodesic Systems, a maker of memory management/debugging software, has a live demo of their Linux product running on the Mozilla nightly builds. It's pretty damn slick -- it detects memory leaks and can show where in the code the leaked memory was allocated and actually recover (GC) the leaked memory. The Mozilla reports actually look pretty good, which jibes with my own impressions of how much it has improved -- see for yourself."

Comments

Alternative memory debugger

[nzkoz]

As an alternative to this one and purify, I've been using valgrind lately (http://developer.kde.org/~sewardj/). It's defintely worth a look for those of you who don't have access to these commercial tools.

Of course it doesn't do much in the way of garbage collection (well, anything) but it's still a great tool.

Maybe not as pretty, but does the same thing...

[lordpez]

CCMalloc also detects memory leaks and shows you where they took place. Even uses the GPL! It might not be as easy to use (you link your program to it during compile instead of running the it on a completed binary), and doesnt have a web interface, but its functional, and has been out for years.

I bet someone could write a ld_preload kind of thing that calls ccmalloc, and you could run it on the completed binary as well, so you could run 'ccmalloc ./a.out' just like the 'gsinject -d ./a.out' of this product.

Here is ccmalloc's page.
http://www.inf.ethz.ch/personal/biere/proje cts/ccm alloc/

Re:Just what they need...

[Mr.Intel]

Their Analyzer product order page shows a drop down for Linux, Solaris and WIndows 2000. My guess would be they have a port already.

Re:Debugger integration?

[charles fiterman]

We have a product that fixes premature frees. This means it will (if asked) ignore all frees and only collect memory when there are no more references to it. It will also eliminate storage leaks. This one isn't a debugging tool in that it doesn't point you at the bug, it just fixes it. We keep hearing people say "I'll go with that if I can take the speed hit." So they connect it and speed improves some times by multiple powers of ten. This is because sand is faster than rust. A single page fault can be slower than many collections combined. So if we eliminate storage leaks and prevent page faults the time we spend doing it is swamped by the time we save.

Open Source gives back

[Anonymous Coward]

This is a great example of the Open Source community giving back to private companies. Geodesic tests an OSS web-browser, and Slashdot stress-tests their web server.

memory leaks, moz, and slash

[Alien54]

I know that when I have moderator status here on slash, I can watch the system resources disappear down a block hole if I hit a story with a lot of comments and I use Moz.

You can hear me screaming down the street.

It is a little better under IE, but I prefer to use Moz.

Memory Usage Trends

[joelgrimes]

Over the last 6 months, every time I download a nightly or milestone, I've been recording the results of the following test.

Download the installer and run it. Moz will launch automatically after install. Kill Mozilla and restart it. Bring up the task manager to see how much memory is used.

Here's the results I've had on my W2k box:

2001 10/01 build 03 22,540k
2001 10/15 build 06 21,876k
2001 10/18 build 03 21,692k
2001 10/23 build 09 21,984k
2001 11/16 build 03 21,952k
2001 11/29 build 03 21,656k
2001 12/06 build 03 19,868k
2001 12/10 build 03 19,812k
2002 01/07 build 03 18,124k
2002 01/14 build 03 19,064k
2002 01/17 build 04 19,244k
2002 02/26 build 03 18,608k
2002 03/06 build 04 18,220k
2002 03/11 build 04 17,704k (build 0.9.9)

That's a decrease of almost 5 megs in memory usage over six months - all the while they've been adding features.
Significantly, they've added venkman, tabbed browsing, the dom inspector and favicon support.

Also significant - I don't know why I bother to get the talkback builds anymore - I haven't submitted a crash in 3 months. And I run it all day, every day.

memprof

[Arethan]

I tried mentioning this in a thread, but it was too quickly drown out. There is a free product that does ld_preload style memory leak detection. It even does memory allocation profiling, so you can find that hidden 'for' loop that is responsible for that extra 15MB of allocated memory. The gui is done with gtk+, so it's easy to use, and will run on most any linux distro these days.

It's available at http://people.redhat.com/otaylor/memprof/
Freshmeat has an entry for it as well.

Re:Is there some other Mozilla out there

[Aexia]

Be aware that while Mozilla is physically slower and more memory hungry, it's still a lighter browser over all. It takes around 66% of the download space of a recent MSIE, despite also having email and IRC and whatever, and even manages to be smaller than Netscape.

It may be slower and consume more resources but at least it uses less disk space?

That's really not an argument the open source community should be making.

Re:Garbage collector

[sporty]

For fun and profit!

1. Do obscure pointer arithmatic for fun.
2.
3. Profit!

Sorry.. I couldn't resist :)

Memory Leak Detectors and Garbage Collectors

[Taco Cowboy]

I'm gonna need people's help to add to the list below.

Here is a list of (freeware) Memory Leak Detectors and Garbage Collectors -

ccmalloc
http://www.inf.ethz.ch/personal/biere/projects/ccm alloc/

Valgrind
http://developer.kde.org/~sewardj/

Boehm Collector
http://www.hpl.hp.com/personal/Hans_Boehm/gc/

Parallel Collector on Message Passing Environment
http://www.yl.is.s.u-tokyo.ac.jp/gc/dgc/

If there are more out there, would you kindly add what you have to the list, please ?

Thank you !

Nice leak detectors built into Mac OS X

[Mneme]

The Mac OS X's malloc library has built-in support for providing good leak detection. The command line tool leaks (installed with the free developer tools). Although leaks can be run on any program, it works best when you set the enviromment variable MallocStackLogging, which causes the system to provide complete stack frame information about when each piece of leaking memory was allocated.

Also of interest are the malloc_history and heap command-line tools. They tell you lots of interesting information about exactly what is on the heap and how it got there. The malloc library also detects double frees by default (making it immune to the recent zlib security vulnerability) and can also detect writing on free blocks, etc. Very nice.

Finally there is a graphical application, MallocDebug which provides similar information on memory leaks and memory use but also provides an easy to use memory-browser interface. Unlike simple leak detectors, you can explore your program's memory space and discover memory that isn't strictly "forgotten" by your program (it still has valid references to it) but should perhaps have been deleted anyway (e.g., finding memory allocated for a splash screen graphic). This last application requires that the code use a special library, but it is easy enough to make dynamically-linked programs use this library (thanks to Darwin's equivalent of LD_PRELOAD, DYLD_INSERT_LIBRARIES).

Although you can debug any code with these tools (from command-line tool to X-windows, Carbon or Cocoa app), they really shine debugging Objective-C, because Objective-C provides enough runtime information for the tools to tell you lots about the objects that are sitting there on the heap.