Slashdot Mirror
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."
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?
Yep, Paul Nettle's little memory manager rocks. It WILL find leaks in your program. http://www.paulnettle.com/ (Yes, you have to navigate through a horrible flash site to get it, but it's worth it).
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...
I haven't used it for a while, but I used to use Bruce Peren's efence 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 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.
Hmmmmmm
8 of 13 people found this answer helpful. Did you?
>> 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.
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.
o r.asp
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/visualleakdetect
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.
Another link you might like to read (just done some search on google):r k.html
http://www.idiom.com/~zilla/Computer/javaCbenchma
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.
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++.
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.
Use valgrind.
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
Other runtime commercial tools - BoundsChecker, Purify, etc
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.)
Just junk food for thought...
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.
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.
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.
[
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...