Slashdot Mirror
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."
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.
Cheers Koz
It does work on win32!
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.
./a.out' just like the 'gsinject -d ./a.out' of this product.
e cts/ccm alloc/
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
Here is ccmalloc's page.
http://www.inf.ethz.ch/personal/biere/proj
Their Analyzer product order page shows a drop down for Linux, Solaris and WIndows 2000. My guess would be they have a port already.
ASCII tastes bad dude.
Binary it is then.
We do have one. Try www.geodesic.com
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.
If you're writing C++ programs, you should be using a garbage collector, such as Geodesics, or the Boehm collector available freely on the net. I've heard various objections to collection, mostly boiling down to speed issues. At least with the Boehm collector, you can choose to manually manage some memory yourself. In that case, it should be treated as an optimization problem. Write your program with the collector, then profile it. Anywhere you can pinpoint the collector as a major slowdown, handle the memory yourself.
If tits were wings it'd be flying around.
Actually, ccmalloc has a mode like purify to automatically link itself in during the compile process. Not the same thing as preload, but it's just as easy. If you're using, say gcc, change your compiler from "gcc" to "ccmalloc gcc" and ccmalloc will do the rest.
:)
ccmalloc is a great utility to have if you can't get your hands on purify
F0 07 C7 C8
> I must confess that since Purify is not
:
> available for Linux, we are always looking for
> interesting pieces of software to do this job.
> Now the only question I have are
> 1) can it be used as a debugger too ?
Yes
> 2) how does it compare to other systems like electricfence ?
Take a look at the demo (perhaps when it is less slashdotted) and draw your own conclusion. It is pretty self-explanatory.
Once they've recovered from their thorough slashdotting I'll have to go check 'em out. Efence alone has saved me multiple weeks of debugging time, allowing me to track down memory leaks in our horrid application instantly. This translates into thousands of dollars of development time that can be put to more productive use. I'd estimate that efence has saved my group over 12 thousand dollars in debugging time this year. Now if only I could convince the boss to channel even a small portion of that back into the open source community...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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.
Textbooks and Open Educational Resources
Make sure you delete all your old profile and setting files before you reinstall again. Installing over a previous version causes problems.
t all
see: http://www.mozilla.org/releases/mozilla0.9.9/#ins
fellow Slashdot user and hacker extraordinaire.
Thank you Bruce, for all you've done for Free Software.
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.
Stupid job ads, weird spam, occasional insight at
Geodesic supports HP-UX, Linux and Windows under Cygwin.
Years ago in my employment, that is.
If there is interest, I might recreate it for the Public Domain. It should only take a weekend.
The principle is simple: go through all writable memory (including the stack and the registers). The idea is -- and I didn't invent this -- what looks like a pointer [to the heap] is a pointer. Those heap blocks that were not pointed to, are reported as garbage.
A special allocator package records the calling frame so you can tell where the block was allocated. Other niceties are included. The tools is implemented as function calls that you typically invoke from the debugger.
While the principle is heuristic, the practical experience (with Solaris and Interactive UNIX) is that it instantaneously finds all garbage.
Marko
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/cc
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 !
Muchas Gracias, Señor Edward Snowden !
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.
A more basic question to ask, however, is why something like Mozilla has memory leaks in the first place. Avoiding memory leaks in C is hard because there simply are no hooks in C to automate resource management. But C++ has constructs that make writing leak-free code and code that doesn't use bad pointers pretty easy. Since switching from C to C++ a few years ago, memory leaks and bad pointers have simply not been an issue anymore in my code.
Have you tried out the one at http://spellchecker.mozdev.org?
the good ground has been paved over by suicidal maniacs