What Memory Leak Detector Do People Use? 29
funnymalloc asks: "A quick search for 'leak' on FreshMeat yields a whole slew of projects/products which claim to help one find and kill memory bugs of various types when using C/C++. ccmalloc, debauch, dmalloc, LeakTracer, libyama, MCheck, MemProf, memwatch and mpr show up on the first page alone. Ideally a product would detect all of the common problems: array over/under runs, write to unallocated memory, write to 'freed' memory, unfreed memory (a leak) etc. And would work with both new/delete and (m)(c)(re)alloc/free. My question is which of these projects/products do people use and like? (and no, Java is not an answer)"
Fortify! (Score:1)
Memory Debugger (Score:3)
Binder
Java is not the answer... (Score:5)
Java does a wonderful job with the simple stuff that you mention. It checks array bounds, does not let you write to unallocated or freed memory, and a slew of other runtime checks. Java however does not eliminate memory leaks.
To be able to be freed (by the garbage collector) an object must have no references. Accidentally keeping references around is a lot easier than you might think and can be a huge source of memory leakage.
Dr. Dobb's has an article [ddj.com] about this.
I love Java and I prefer using it for most of my projects, however anybody who tells you that it solves all your memory leak problems is blowing smoke out their ass.
Re:Armchair Programmer (Score:1)
"My programs *never* fail cuz I'm l33t!"
My god. Have you ever programmed anything?
Programmers make mistakes.
Experienced programmers make fewer, but more subtle, mistakes. In response to the *asked question*, which you *don't* answer, dmalloc has been my favorite for years. it's free, it works, and it's not difficult to use. checkergcc gccchecker or whatever it goes by today was always crashy and problematic, and electric fence is neat, but I like dmalloc more. Always had trouble getting efence to do what I wanted.
purify (Score:1)
Leaky (Score:3)
HuH? (Score:2)
Oh, I understand now, should have been an extra comma in there, right?
None (Score:1)
When you insert a malloc() in your code, be sure to make it clear to yourself "who" or "what module" is responsible for that memory, and be sure to hold it responsible for freeing it again. If you are object oriented, this is even easier.
Programmers that write programs that allocate memory, and then get back to them to insert free() statements when the programs are to be used in practice, should be fired ASAP.
Don't program by coincidence [pragmaticprogrammer.com], Think!
GC Malloc (Score:3)
Hans Boehm's garbage collecting malloc() can be built in a leak-detection mode. It works really well once you figure it out.
http://reality.sgi.com/boehm_mti/gc.html
ElectricFence is good at finding over/underflow problems.
Purify (Score:3)
You didn't mention a platform. I'm assuming some sort of Unix, such as Solaris or Windows.
Rational Software (I think) makes a product called Purify. If you ever work in a large shop, you'll use purify to help write your software.
Click here to go to their website [rational.com]
It not only catches memory leaks, but also uninitialized pointers, using uninitialized RAM, stack overflows, etc. It is, in my opinion, the best tool on the market. Yes, it does cost some $$$ (about $2500 per license). If you can't afford it for whatever reason (your a student, business doesn't have the money, etc), or you need a Linux solution (not purify - yet), you'll have to go open source. I would be thrilled if Rational released their tools on Linux, too, although I have to wonder how many Linux developers could afford to buy them (probably the reason they haven't released for Linux yet).
Re:Memory Debugger (Score:1)
Re:None (Score:2)
Case in point. Quite a while back I was involved with writing a multithreaded application which (among other things) got events from various sources. Many of these events contained data which several of the running threads needed to look at or keep. Instead of memcpy()'ing the the data block for each process, we wrote a "multithreaded" memory manager. Basically the event "receiver" was responsible for malloc()ing the block. Each thread would then be given a pointer to the block and then each thread could do what they needed to do with it (read-only of course). When they were done, the thread would issue a call to a free()-like function which would basically de-increment a counter of how many threads had a pointer to the process.
Add to that the complexity that some threads could "duplicate" the pointer and hand it to another couple threads (such as a outbound communications threads, etc. etc.). Add to that that some of this data ended up pointed to in a long-term linked list, etc. etc.
All it took to cause a memory leak is missing one free out of hundreds. We ended up adding code to keep track of which threads had "unfreed" pointers assigned to them so we could track it down at least to the thread.
Custom-built library (Score:1)
It may mean your code needs changing before being released into the world, but at least it is platform / compiler independent. And if it's a toy / prototype / uni assignment then efficiency isn't an issue and you can leave it in.
Memory leaks... (Score:1)
9 out of 10 windoze designers use... (Score:1)
Blue screen of death. Works almost everytime!
I just had to put those $0.02 in...
Laugh - it's kind of funny...
Gods yes! (Score:3)
Powerful vs simple. Pick one.
--
MailOne [openone.com]
It seems obvious, but... (Score:1)
C is great for writing kernels and drivers. Java is okay for JSPs and the like. Other choices exist that are far, far better for one-person or large-scale projects. Eiffel, Dylan, Lisp, and ML dialects can work well for big projects and provide very good runtime performance. Python, Ruby, and Smalltalk are great for individual use and are usually fast enough for a given purpose.
Just did some research (Score:4)
MallocDebug [colorado.edu]
Thu Dec 21 13:26:01 CST 2000 - overview of malloc debugging
tools. looks good.
mpatrol [demon.co.uk]
Thu Dec 21 13:37:30 CST 2000 - didn't try it out,
but the documentation actually lists
"related software", which indicates to me they did their
reseach.
glibc builtin [sdb.suse.de]
Thu Dec 21 13:43:54 CST 2000 - evidently glibc has debugging
stuff built-in.
Re:No, but it's DAMN good. (Score:1)
Yes, Insure does. While costing quite a lot, it does detect all(?) memory leaks, and all invalid memory accesses. Slows down the program to hell, but produces all the valuable output you may need.
Re:Memory Debugger (Score:2)
Electric Fence [freshmeat.net] is good. So is YAMD [freshmeat.net].
Electric fence has the advantage of working on non-Linux systems like HPUX, Solaris, etc., while YAMD is for Linux/x86 or DJGPP only. YAMD does the same segv thing as Electric Fence, but it can also produce a log file which is invaluable for finding memory leaks. I think it can detect most (all?) of the problems that the original poster mentioned. YAMD can also be linked to your program at runtime, unlike Electric Fence, which I believe requires you to relink.
Molly.
Re:Purify (Score:1)
I second the call for Purify. While it's expensive, so am I.
Re:purify (Score:1)
Too bad they're not good enough for this level of quality-per-price.
Lots of companies who sell products for Linux think/know they can keep up with it.
If, however, the quality-per-price of the free-world exceeds all of the propriety world, its all great for us users.
kill -9 properiety
Re:purify (Score:2)
Unfortunately, it is completely useless now unless you're working on NT or Sun or one of the other few platforms it supports.
If you like GNU project software, there's a package called Checker [gnu.org] which aims to do many of the things which purify does. I haven't used it much though, so I can't comment much on its usefulness.
Cryptnotic
mpatrol (Score:1)
I wrote the first hit -- "leak". (Score:2)
I first run the program to create a baseline on memory utilization. I run it again after a period of time (1 day, for example) to see what has increased. A sysadmin would want to run this on a box that is losing virtual memory over time, and without a good explanation.
I used it to find some problems with some java code, and with the Sybase Replication Server. Their heaps were growing and growing over time.
Of course, this won't catch *everything*. Like short running processes or ever increasing number of processes. Or kernel memory bloat. But it's helped me figure out a few weird problems here and there.
Probably of marginal use to programmer types. This is more for the SA trying to find the bad guy. Cheers.
Re:GC Malloc (Score:1)
Firstly, C\C++ gc'ers are conservative (wrong, slow).
Secondly, writing in C\C++ usually means the programmer handles most of the management in the fastest possible way. Conservative GC's are very slow. If he's not writing for performance, why write in C\C++?
No, but it's DAMN good. (Score:4)
Pretty much the only place we have to care about resource and reference cleanup is with JDBC. Those instances when we have had problems (always with JDBC ResultSets not being closed), a $500 tool called OptimizeIt has been able to show us what line of code caused the problem with less than five minutes of total time devoted to the problem.
So, while Java is not perfect, in my experience it cuts down by 99% the total amount of time and effort you have to devote to memory related issues. With a dozen Java newbie developers adding 60,000 lines of code to an application over a year period, as the lead programmer who deals with such problems, I've spent two hours on memory management issues. No memory checking tool for C and C++ do that.
GNU Checker is the most sophisticated (Score:2)
Re:No, but it's DAMN good. (Score:1)
Maybe it's the specific JVM I'm using, but if I get sloppy in JNI the JVM crashes hard. That can be frustrating at first, since it'll crash at the drop of a hat, but after a while you realize it's good, since it keeps memory problems out. It even crashes when you exit a JNI method without free()ing all malloc()ed memory. Unfortunately, it doesn't provide much info on what happened. The bad part is forgetting to DeleteLocalRef()s - they can bloat up the JVM real fast.