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)"

Fortify!

[swright]

I'm surprised nobody's mentioned fortify - its an excellent set of stuff that traps all of the problems mentioned above - and can be enabled/disabled quickly and easily (lets not forget the performance hit that these things have...) I can't find a URL offhand (why isnt it in the source files i wonder..) but it should turn up in searches... ...or email me and I'll send it to ya.

Memory Debugger

[Binder]

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 is not the answer...

[DeadSea]

When you say that Java is not the answer, you are more right than you may know.

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

[Anonymous Coward]

I hate it when people say stuff like that.
"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

[Tharsis]

well purify is, afaik, _the_ best tool for this (and more) but unfortunately it's not free and the people of rational are too stupid to support linux:/

Leaky

[AT]

Leaky [mozilla.org], from the mozilla project, works really well. It works with any C or C++ project.

HuH?

[crisco]

I'm assuming some sort of Unix, such as Solaris or

Windows.

Just had to be the one to point it out.

Oh, I understand now, should have been an extra comma in there, right?

None

[Fellgus]

A memory leak is a sign of bad design. If you have it, rewrite your code.

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

[pthisis]

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

[jmaslak]

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

[nadachicken]

I've had great luck with Electric Fence, it even smacks your hand when you mix new/delete and *malloc. Too bad it doesn't keep me from writing crappy code in the first place.

Re:None

[fwc]

Not to start a flame war, but a memory leak is not necessarily the cause of a bad design, but instead of stupid, hard to find errors. Kinda like that infamous misplaced semicolon.

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

[Andjam]

If you're working on your own, then you may want to use routines zalloc, zfree, etc. that call the usual malloc, free, etc. , except that it asks for a larger chunk of memory and have at the edges magic numbers that you can check don't change. You can also get these routines to keep track of how much has been asked for and freed.

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...

[sithlord2]

I use a memory-tracker library I found at www.flipcode.com [flipcode.com] in the "ask midnight section" [flipcode.com]. It works pretty good...

9 out of 10 windoze designers use...

[glebite]

Blue screen of death. Works almost everytime!

I just had to put those $0.02 in...

Laugh - it's kind of funny...

Gods yes!

[OlympicSponsor]

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 [openone.com]

It seems obvious, but...

[Eidolon]

...if you think you need a leak detector, what you probably need is a language with real garbage collection. There are lots to choose from nowadays, most of which can either be compiled natively or translated to some dialect of C and complied, so you can use good ol' gcc if that's your heart's desire.

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

[reverse solidus]

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 [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.

[Peaker]

No memory checking tool for C and C++ do that.
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

[Molly]

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

[jamiea]

I second the call for Purify. While it's expensive, so am I.

Re:purify

[Peaker]

They're afraid they'll be outdone by programmers who can offer better quality-per-price ratio?
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

[Cryptnotic]

Ahh, yes. purify [rational.com] is an amazing tool. I used it on a huge research project I was working on a few years back. It found so many obscure problems.

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

[graeme.roy]

I wrote mpatrol, which attempts to combine as many features of the other malloc debuggers/leak detectors that were mentioned on as many platforms as possible. It also adds a few features of its own. I also collected a list of related software and wrote an overview of their features at: http://www.cbmamiga.demon.co.uk/mpatrol/ If anyone's got any other software that they can recommend for solving such problems then let me know. Incidentally, I agree with the poster who wrote about GNU Checker. Unfortunately, the run-time library for it only works on a few platforms. I'm aiming to add Checker run-time support in mpatrol (initially for heap memory) to extend this to all the platforms that mpatrol runs on. Graeme.

I wrote the first hit -- "leak".

[AtariDatacenter]

I guess it depends on how you want to go after leaks. I wrote the first hit your search found on Freshmeat called "leak". I was looking at memory leaks (or increased memory usage that wasn't necessarily a "leak") on a system with a large number of different long-running processes.

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

[Peaker]

Kind of defeats the purpose of using C\C++, doesn't it?
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.

[brad.hill]

What you say is true, but in my experience working on a relatively large Java project with over a dozen developers with very little C and Java experience, we give almost zero attention to memory management issues. We have a large servlet application that we run hundreds of thousands of transactions through with no appreciable growth in memory usage, so it's not like we just ignore problems; I can confidently say there aren't any of any consequence.

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

[nedow]

The best memory state analyzer available for Linux is GNU Checker [gnu.org]. 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.

Re:No, but it's DAMN good.

[ddstreet]

Java is damn good at memory management - but even more suprising is JNI!

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.