Memory Checker Tools For C++?

An anonymous reader writes "These newfangled memory-managed languages like Java and C# leave an old C++ dev like me feeling like I am missing the love. Are there any good C++ tools out there that do really good memory validation and heap checking? I have used BoundsChecker but I was looking for something a little faster. For my problem I happen to need something that will work on Windows XP 64. It's a legacy app so I can't just use Boosts' uber nifty shared_ptr. Thanks for any ideas."

two points

[sentientbrendan]

This isn't really an answer to your question, but it's on topic and there's some questions I wanted to get answered myself.

First of all, shared_ptr is going into the standard library as part of TR1. Does anyone know when common development environments, i.e. GCC and MSVC, will start including TR1?

Second, I believe that there are a number of garbage collectors available as libraries for C++. I've heard boehm's garbage collector mentioned numerous times. My question is, are any of these libraries any good? Are they really practical to use in real world applications? Do you have to modify all of your types to use it, or can primitive and stl types work with it?

Fluid Studio's Memory Manager (MMGR)

[Rezonant]

Yep, Paul Nettle's little memory manager rocks. It WILL find leaks in your program. http://www.paulnettle.com/ [paulnettle.com] (Yes, you have to navigate through a horrible flash site to get it, but it's worth it).

Boost? Ugh

[Viol8]

Talk about a sledgehammer to crack a nut. Boost strikes me as the sort of library used by people who want to show off how up to date their skills are , not people who really need to write a program to get a job done. Its bloated , has a wierd syntax that differs from the C++ norm and doesn't solve any problem that isn't already solved or could be done quite easily by standard C++ anyway. What is its point except as intellectual masturbation by its authors? No this isn't a Troll, this is a post by someone who was forced to use Boost for a year and I loath it. Yeah , mod me down , whatever...

Re:Boost? Ugh

[pzs]

I would be inclined to agree with this. I used the Boost Graph Library for some research code a few years ago. It's been designed to be extremely generic, which although a good thing sometimes makes it pretty difficult to just start coding something without all the bells and whistles. For operations on graphs, such as walking through, you can use their specialised functions for doing things but it takes days and days to work out how to use them and I ended up just using regular loops because they were much easier to understand.

Getting it to compile was a bit of a nightmare too. It has its own native compilation management tool that you have to download as well. What the hell is wrong with using make like everybody else? It also uses a very complex template hierarchy that produces terrifying error messages.

I'm sure that once you become an expert, BGL is really powerful and efficient, but I found the learning curve too steep. I just want to get in and build a working prototype quickly so I can see what I'm doing, not spend hours wading through manuals and examples to build the simplest program.

I'll be with the parent post and get modded a troll by boost developers.

Peter

eFence

[cannonfodda]

I haven't used it for a while, but I used to use Bruce Peren's efence [perens.com] for bits of malloc debugging, it hasn't been actively developed for ages but it's pretty light weight if that's what you need. There appears to be an up to date branch DUMA [sourceforge.net] which I haven't tried. As far as I remember you can use efence under WIN and DUMA claims to work......

Unfortunately, what you prolly want is valgrind or purify.

Re:Most tools I've tried are useless

[cerberusss]

They might be useful for small apps but if you have a massive app they are almost more trouble than they are worth.

I'm of the opinion that the larger the application, the harder it is to write. So my philosophy is to chop programs up in different processes. The fact that you're stating that the memory checkers are only useful for small apps, might be a sign that your app is too big.

Re:Fluid Studio's Memory Manager (MMGR)

[Anonymous Coward]

It seems to be single-thread only?

Re:Most tools I've tried are useless

[ShakaUVM]

>> foster safe coding practice

Agreed. Most skilled coders I know don't write code that has memory leaks. Even simple things like making sure your source code looks symetrical, matching allocations with deallocations (of whatever flavor), etc., is usually enough to avoid any problems with memory. It's easy (easy!) to write loops that never overflow, though you wouldn't know it with the amazing number of overflow exploits that have been found over the years.

However, it gets nasty when dealing with legacy code that is already leaking, or when you unfortunately get partnered with somebody that doesn't know how to practice safe coding techniques. In those cases, I guess these sorts of tools are useful.

Visual Leak Detector

[Tucano]

I have tried mainly Boundschecker and Purify, and they were usually quite slow and difficult to set up and produced lots of spurious results. Also, quite often they simply didn't work at all and refused to run certain programs. A few years ago I reduced the problem to a 10 line C++ program that would crash Boundschecker or Purify, can't remember anymore which one it was.

In any case, Visual Leak Detector is a free memory checking tool. It's only for Windows / Visual Studio, but if you are using that, VLD is awesome: http://www.codeproject.com/tools/visualleakdetecto r.asp [codeproject.com]

It's super easy to set up, just #include "vld.h" somewhere in your program, and then run the debug mode. No need to rebuild everything in instrumented mode, and no false results (at least I haven't got any). Real memory leaks will be reported in the output window of the IDE.

Re:Valgrind

[HRogge]

Another link you might like to read (just done some search on google):
http://www.idiom.com/~zilla/Computer/javaCbenchmar k.html [idiom.com]

Of course you can create your own "dynamic" allocator in C++... but that doesn't make allocation/deallocation automatically faster.

Maybe you should search for some numbers to support your argument... just by stating "I don't buy it, C++ is still faster" it doesn't become reality.

Re:Valgrind

[DrXym]

By the way, you're not missing out on anything special by not programming in Java or C#. Both of those languages are slow, and introduce their own language complexities. -bms20

Speed isn't everything. If your server application is network or database bound then stability and API richness is considerably more important than speed of execution. After all, does it matter that your app completes 2ms faster if it has to wait 500ms for the database to return? Or that it crashes more frequently? Or that you can't port it to new hardware because half the libs you use don't compile? Since Java offers dozens of cross-platform APIs (network communication, web services, XML parsing, crypto, database, RMI etc. ) and runs (without recompiling) on dozens of platforms AND is generally harder to bring down than C++ I would favour where speed and UI are not factors.

Even where a UI is present, Java has it's uses. Eclipse demonstrates that Java can produce excellent cross-platform desktop applications. I think Java's weakness is definitely its UI though. While Swing is a very rich API, it's also hard to write native look and feel apps. The file picker dialog is one place where Java apps always suck. Poor look & feel is probably why Eclipse chose to use SWT instead.

C# (.NET) obviously doesn't benefit from robust cross-platform support but it does inherit most of the same advantages of Java. It also has excellent UI support (and better layout tools) on Windows meaning that you can accomplish quite a lot in C# without dropping to C++.

Re:Purify

[0123456]

Yeah, I haven't used Purify in a few years, but when I tried it out it seemed very effective and found some bugs that would have been hard to track down otherwise. We didn't use it in the end because, at least at that time, it didn't like us dynamically generating machine code... otherwise it was better than anything else we tried; for normal C and C++ code it should work well.

Re:Boost? Ugh

[MikeTheMan]

I pretty much had the exact same experience. I tried to use the Boost Graph Library to create a visibility graph for a motion planning problem, and while it eventually did work, it was painful to get it working. At one point, I spent 3 hours (!!) trying to get the program to just compile. Errors were awful, kinda like STL errors but on steroids. In a standard-size terminal, each error took up about 8 lines.

And they weren't helpful errors, mind you. Due to some template magic, something had broken, and instead of telling me what really happened, Boost (at some point during compilation) replaced a template with an actual class called boost::error_property_map_not_found. What followed was a slew of errors saying that boost::error_property_map_not_found did not support the + operation, or the - operation, or...you get the idea.

The library seems plenty powerful. I think it would benefit from more examples, though. LOTS more examples.

Re:Boost? Ugh

[Rakshasa Taisab]

Erhmm... As I read the two parent comments, it's obvious you don't know _what_ boost really is.

It's not primarily meant for production use, rather it is a _testbed_ for future improvements to the C++ standard library. Pretty much a place where they intentionally test the bounds of the C++ language and check what kind of features would make sense in the standard.

Re:two points

[shutdown -p now]

too many developers use it for lifetime management (bad).

Why is it bad? Isn't the whole point of shared_ptr to automatically manage the lifetime of a shared resource?

Re:two points

[Craig Ringer]

gcc has included most of tr1, especially <tr1/memory>, since at least 4.1. I think it was in 4.0 as well.

It's a pity there's no way to ensure compatibility between boost::shared_ptr and std::tr1::shared_ptr , nor a really attractive non-preprocessor-reliant mechanism to switch between them (since typedefs in C++ do not work on incomplete template types).

valgrind

[nanosquid]

Use valgrind.

Re:um

[Anonymous Coward]

Application Verifier from MSFT is the best free tool you can get (just make sure you have good symbols, as with all run-time checkers!) - http://www.microsoft.com/technet/prodtechnol/windo ws/appcompatibility/appverifier.mspx [microsoft.com]

Other runtime commercial tools - BoundsChecker, Purify, etc

Re:Boost? Ugh

[N7DR]

I'm used to templates syntax (though I think its ugly and Stroustrup could have done a lot better)

I was on the C++ committee at the time that templates were accepted -- my memory is that the syntax that was accepted is identical to what Bjarne originally proposed, because there were no obvious flaws in the proposal.

It is true that if templates were being added today, I would expect the syntax to be rather different, but only because we had no idea that when we added templates we were adding a Turing-complete compile-time language. Had we known that, I am pretty sure that we would have also introduced a syntax that makes it about a million times more pleasant to actually use that feature.

Re:Boost? Ugh

[Viol8]

Are you seriously using those examples as an argument FOR readability?? I hope you're just being sarcastic.

Re:Roll Your Own

[Doctor Memory]

Exactly my experience. I didn't know Electric Fence existed (and it may not have, this was back in '92-'93), so I wrote my own malloc replacement with bounds checking. It didn't eat up much more memory (I think around 64 bytes/allocation) or use a whole lot of CPU (basically, it walked the heap checking for corruption every N allocations, and N was configurable down to 1).

I still remember the first time I tested it; I allocated some memory, then dumped the heap. I saw the block I had allocated, but there was another 2K block allocated that I hadn't! Fortunately I was dumping the contents along with the size, and I quickly figured out that printf() was calling my allocator too! (I had written replacements for [mc]alloc() and free(), and used the same names so I could instrument existing code w/o having to rewrite it.)

Re:Valgrind

[DrXym]

I think my perspective is rounded because I'm in regular contact with C++, Java and C# every day at work. I wouldn't dream of using Java for something performance related (or I'd at least use JNI to fix the performance bottleneck) and I wouldn't dream of using it for a lightweight GUI app that I expect launch quickly.

However I think Java is just fine in most regular roles assuming performance is no issue. I've never thought to myself that Azureus is any slower because its implemented in Java. I've even written a poker hand calculator that runs through hundreds of thousands of hands in a second. I think performance is an overrated concern for most apps.

Even so, I still find it easier to knock together a GUI app much easier using C++ than I would in Java. Swing layout editors just stink. I don't understand what the big hangup is with Swing and visual editing since DevStudio 2005 makes it look easy with .NET 2.0.

Recent real world example

[2DGamer]

I can attest to this. A few months back I was doing cross development for FreeBSD/Linux and maintaining a development version for Windows.

My code worked fine in Windows - mostly, but still a bug remained that I suspected was in the renderer but couldn't prove it.

The code ran fine on FreeBSD without any problems but I couldn't run it for more that a few minutes on Linux without it crashing hard but at random times.

I ran my Windows code through BoundsChecker (which I've used for years and have found to be very effective). Came up fairly clean, I fixed a few things but I could not find the bug.

I wasn't familiar with any Linux debug tools but eventually tried Valgrind. It found the problem after the first run, and BoundsChecker didn't even give me a peep. I found I was stepping just outside a graphics buffer at certain times and writing in memory I didn't own. It was enlightening the bug was in the same code for FreeBSD/Linux/Windows but displayed completely different behavior.

Anyway, I have respect for Valgrind. Now, if it was only available for FreeBSD.

Re:Don't allocate or free = no leaks = need no too

[Speare]

I don't mind if an implementation of STL has some hidden/private/singleton allocation pools behind the scenes to speed things up. What I find really friggin' annoying is that they never track those allocations and offer any form of "reset" function that you can call before exiting your app, so that the simplest global malloc-counting methods can audit for leaks. You shouldn't need an "SGI-STL-aware-and-compatible leak detector," you should only need a malloc leak detector.

Re:Roll your own!

[Anonymous Coward]

Yes,

Rolling your own is much easier than it sounds. Reference counting can be done by mere mortals.

I would say that using a self-programmed memory checker to keep track of memory leaks and then fix them in your code is better than just tossing the mis-allocated memory manually. This way the memory checker can be tossed in the release version, leaving lean and mean c++ code - which is why you code in c++ anyway.

Also, most serious memory leaks are the result of conceptual confusion within code and not a simply a matter of failing to write a delete for each new. In a garbage collected language, the same confusion leads to memory hogging, stuck-loops and data-corruption. Thus c++'s lack of automatic memory management mean may seem like a terrible problem but isn't that much worse than other languages because no language can save you from your own stupidity.

Ta...