Slashdot Mirror
What Memory Leak Detector Do People Use?
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)"
Electric Fence tends to work quite well and will check for most types of memory violations. It actually segv's your code when you perform a bad memory access, this lets you run in the debugger of your choice and see exactly where you made the mistake. Your code does run slower and take more memory but most memory debugger behave this way.
Binder
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 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.
Leaky, from the mozilla project, works really well. It works with any C or C++ project.
Oh, I understand now, should have been an extra comma in there, right?
Bleh!
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.
rage, rage against the dying of the light
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
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).
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.
I tried LeakTracer--works great, but ONLY checks new/delete and ONLY on i386. mpr checks new/delete AND *alloc/free, but doesn't seem to like my multi-threaded app. Neither of these check access violations. I found another one that did EVERYTHING (including telling you where you should put the free/delete) but it required re-writing the app to use their macros.
Powerful vs simple. Pick one.
--
MailOne
Non-meta-modded "Overrated" mods are killing Slashdot
(Hey Ryan! Here's your proof!)
I used ElectricFence, mainly because I happened to already have it installed. It helped. There are a bunch of others, some of them look interesting:
MallocDebug
Thu Dec 21 13:26:01 CST 2000 - overview of malloc debugging
tools. looks good.
mpatrol
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
Thu Dec 21 13:43:54 CST 2000 - evidently glibc has debugging
stuff built-in.
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 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
My other first post is car post.
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.
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.
The best memory state analyzer available for Linux is GNU Checker. Far, far more than a malloc library, GNU Checker is GCC based. Checker automatically instruments every memory access in your code when you compile your code with it. It detects bad calls to malloc/free, memory leaks, uninitialized data structures, and all sorts of other memory problems. I've used almost all the memory debugging tools and libraries on Linux at one time or another. Most of them are pretty good and each has its place. However, the Swiss Army Knife of memory debugging tools for Linux has to be GNU Checker. It is the most sophisticated of the lot, and it's the nearest to Purify in power. Unfortunately it is also one of the best kept secrets when it comes to Linux development tools.