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
'cause I think I'm of the age that most of my memory is leaking all over the floor....
Now where did I put that mop and bucket?
The race isn't always to the swift... but that's the way to bet!
It does work on win32!
Will this directly affect and improve Mozilla on non-Linux platforms? Would it have a use flagging the leaks in the Linux code and then making the code corrections on the OS X platform?
Does this product actually integrate with the debugger. For example, can it break on a line of code before it uses a dangling pointer?
I've been using NuMega products within MSVC for a number of years. I used Purify before that. I haven't used the latest version from NuMega, but I've always had a lot of success with BoundsChecker (memory profiler, error detection, etc), True Time (performance profiler) and True Coverage (code usage profiler).
I wouldn't even know where to start looking for open source equivalents of these products. Can anybody give me any pointers? Preferably for Windows, but also Linux. How does this product compare with the likes of those from NuMega and Rational?
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.
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.
that I seem to be missing?
After reading the Salon article about how improved and fast it was now, I decided to give it a whirl on my NT desktop at work.
I uninstalled it after about 15 minutes. It was just slow. Sluggish in loading pages, slow in creating new windows, everything. Not only was it slower than IE 5.5 but what surprised me was that it was slower than *Netscape* 4.7, which is what I primarily use. It's a shame because it had some nice options.
What am I missing? Is it not meant to run on NT? Is it debugging code? Would it run better on XP? I'd love to give it a chance but apparently, I got some other Mozilla browser instead of the one everyone here is raving about.
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?
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.
You can hear me screaming down the street.
It is a little better under IE, but I prefer to use Moz.
"It is a greater offense to steal men's labor, than their clothes"
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
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
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 !
"How hard is it to manage pointers and free your memory allocations anyways?"
.NET with all their marketing strength.
(To those who didn't get it, I was being cynical)
That is the response I usually get when advising to write using high-level languages that take care of memory management. Finding enormous leakage in huge programs almost proves this response wrong. Finding leakage in almost all programs definitely proves it wrong, and you sure will find leakage in almost every large program written in a low-level language like C or C++.
The overuse of low-level languages with increasingly powerful hardware is becoming appearant to more and more people. It seems the "dark side" will be out of the low-level language hell sooner, as Micros~1 is pushing C# and
If you don't want the Linux/*nix world to stay behind, stop using C and C++ where Python and Lisp can be used. Writing in C or C++ instead of a higher-level language can be deemed as a premature optimization, as any specific part of the program can be optimized and written in C when necessary. We all know how evil premature optimization is.
If you write in C or C++ because that's simply what you know, you should not be wary of learning new languages. You should know that C++ is extremely hellish to learn, while Java is a lot simpler, and Python takes at most a day or two!
From my own personal exprience, functional languages are a bit more difficult to learn and grasp, but it seems they perfectly fit some mindsets.
Stop wasting human power on writing destructors and freeing unused memory, when it can all be done automatically.
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.