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."
boost::shared_ptr is not a memory checker, it's a reference-counted smart pointer, and works fine in legacy apps (such as compiled under VC++ 6).
Boehm's garbage collector is used in Inkscape -- and they did gradually introduce its use, so you can start using it for some things and gradually extend the usage.
Boudewijn
Use valgrind. It's for Linux only, but what it does is invaluable for most of the tasks. I don't know of any other tool of such help.
Note this is not 'memory management tool', but one to help you find and clean up the memory leaks. There is no way to do proper garbage collection using the STL's allocators, though there is a 'gc' library http://www.hpl.hp.com/personal/Hans_Boehm/gc/ which tends to do the job. Haven't used it, though projects like Mono http://www.mono-project.org/ use it extensively.
Purify works quite well. It is big and slow, and doens't play nicely with ACE_Tao stuff sometimes (tao do cleaver things that scare s purify sometimes)
Use valgrind to find the bugs and Hans Boehm's GC to not have to fix them.
If you didn't already know of such tools then go do some research; what you want probably already exists.
I know this isn't exactly what the article is looking for. But, if you are using the STL (which you SHOULD be!) you may be interested to know that the STLPort STL implementation includes a debug mode which contains loads of error checking to make sure you aren't misusing STL.
gcc 4.2 includes a good part of tr1 as was released (late) a few weeks ago.
shared_ptr is a blessing and a curse. It saves you from manually destructing objects held in a collecton (good) but too many developers use it for lifetime management (bad).
PageHeap is a debugging tool for Windows created by Microsoft. It does what you want.
For more information look here:
http://support.microsoft.com/kb/286470
Use valgrind : www.valgrind.org It is (in my opinion) the best tool available for this purpose. In fact, I develop C++ exclusively on linux first because of valgrind, then port to Win32 later. 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
That's a pretty harsh comment. Would you mind please giving some examples?
... // don't need to worry about when 'delete f' happens!
Personally, I find that
shared_ptr f (new Foo);
and also scoped_ptr are simple to use and very useful.
As with a lot of things there can sometimes be a tradeoff between the slope of the learning curve and the expressive power that you get as a result. Yes, there are more than a couple of Boost libraries that are over my head and where I write "standard" code instead. But Boost is not all-or-nothing - you should just use the bits that you like.
It's true that MMGR is single thread only, and if your program allocates and frees memory on multiple threads you should choose another alternative. However, many many programs only allocate and free memory on one thread, and for those MMGR is simple to use and is pretty damn good at finding leaks, overruns and similar problems.
If you use MS compilers the memory debug stuff is in crtdbg.h, IIRC it has been there in one form or another since V1.5 but for some reason seems too obscure for the average Windows programmer to find. ;)
It is a very handy feature for finding leaks, buffer overflows, ect. The only other product I've used to find memory problems on recent incarnations of Windows is Purify. The MS solution is infinitely simpler because it's built into the environment and it's narrowly focused on memory problems. To state the obvious and in fairness to Purify, MSDev is infuriatingly fussy when it comes to building debug modules for IBM's Purify.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
I used to select tools for my team. For UNIX, I selected Purify and for Windows, BoundsChecker. After a few days with BoundsSlacker, **all** and I mean every one of my team was asking for Purify for Windows licenses. 17 licenses later and our code crashes have dropped byat least 90%.
Yes, it isn't cheap. Just do it. You'll thank me.
The productivity increase alone will make it worthwhile for management.
You don't usually need to build anything to use BGL - it's mostly header-only library. It has only two small helper files.
And Boost.Build is muuuuuch more powerful than makefiles. You can try to use Boost.Build v2 in your own projects - it's very very useful.
In 1.34, Boost made a Windows install tool that makes it much more easy to use. Just run the installer, put it in the directory you want, and change the Visual Studio settings to include $BOOST_ROOT. You could easily get going in 5 minutes
;)
By the way, if you're not developing for Boost and aren't using one of 8 or 9 libraries, you don't *have* to run their build system. Just pointing Visual Studio or GCC to $BOOST_ROOT is all you need to do. It sounds like taking 5 minutes to read the "getting started" page would have saved you a lot of grief
Boost is a collection of a lots of libraries and you can use only pieces that suite you. For example, shared_ptr has a very simple usage pattern and solves a problem that wasn't that easy to solve. It is already included in TR1. You really can't say that shared_ptr is bloated, too complicated or that it is a nightmare to compile - it only needs header files! :-) Some boost libraries rely on really ugly hacks (e.g. in boost::serialization - order of include files matters!!) and produce very bloated code, but you should judge it on a library per library basis.
I would also recommend checking scoped_ptr, boost::random, boost::threads, boost::date_time and boost::filesystem. I use them all extensively in a single library that has to compile on gcc (Mac & Linux), MSVC80 and (!) Borland C++.
As for the complaints about the boost build system - bjam. I really have to disagree with you. You *don't* need to use it. Use it only to compile boost libraries, and then integrate them using whatever tool you want. I personally recommend cmake - it generates Xcode, MSVC, Borland projects or simple Makefiles among others... I use it to generate all of these.
Yes, it generates awful error messages, but, one could argue that STL and template metaprogramming in general generate awful error messages. It is something that is deemed to be fixed in new C++ standard.
I will agree with grandparent that some boost libraries are mental masturbation - boost::lambda comes to my mind
Last week on Gamasutra was a good article on memory leak detection, and how to role your own tool:
"Monitoring Your PC's Memory Usage For Game Development"
While the title says it's for game development, I found that the meat of the article applies to any windows developer.
If I saw v1 + v2, how would I know if it's adding the numerical vectors v1 and v2 or appending v2 to the end of v1 ? What if v1 and v2 are not numerical? Or do you think people should just intuitively know that for numerical vectors the + operator means element-wise addition and otherwise it means concatenation?
Boehm's gc is very very good...on par with Java's collector and others. The source needs cleaning up, and some configuration bugs to be ironed out, but it is very good.
In order to use it, you just have to include 'gc.h' in your files, which replaces 'new' with 'gcnew' using macros. Alternatively, you can bypass the standard library and provide a replacement for 'malloc' and 'free', but I did not manage to do that (due to the configuration bugs mentioned above).
I use VLD instead, it gives much more useful info to trace memory leaks than the standard crtdbg.h stuff.... (i.e. a stack trace of where the memory was actually allocated)
o r.asp
http://www.codeproject.com/tools/visualleakdetect
Have a look at memory validator. I don't know if it supports 64 bit applications, but it has a great list of features and is the only decent memory validation tool I've ever seen on Windows.
Also, shared_ptr has been promoted to the draft standard C++-0x so you can use std::shared_ptr.
You'll be able to use C++-0x in gcc-4.3 with a switch.
I also heard that std::auto_ptr is being deprecated (not removed) I guess in favor of rvalue references.
Finally, there is a motion to include garbage collection in the C++ language. This is sponsored by none other than Hans Boehm among others.
I realize this doesn't help immediately.
I have had pretty results from Memory Validator from Software Verify. (m l ) It'll slow down your app but I think it does a better job keeping things close to real time then purify.
http://www.softwareverify.com/cpp/memory/index.ht
-----------
Fight Entropy!!! Fight Entropy!!! Figth Etnropy! !
iFgth Etnrop!y ! giFth tErno!py ! giFt htrEno!p y! --- Well maybe
not...
Use a testing framework like Parasoft's CPP stuff http://www.parasoft.com/jsp/products/home.jsp?prod uct=CppTest
Australian running a company that does C# / C++ / Java / SQL / Python / Mathematica
SmartHeap
The following CRT/Win32 functions can come in handy when diagnosing memory leaks and heap corruption.
Use _CrtSetDbgFlag to get the memory manager to test the heap periodically during use among other things. Or use _CrtCheckMemory to do it strategically.
Using _CrtMemCheckpoint and _CrtMemDumpAllObjectsSince can check to see if any heap blocks have been left on the heap in a range of code. You can use _CrtSetBreakAlloc to break on the allocation to locate the point where a widowed block was allocated.
You can also use GetProcessHeaps and HeapValidate to check heap integrity. In particular, it can be used to check all heaps in the process.
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?
I've deployed Boehm GC in real world applications before now, and consider the quality of the collector pretty good. It isn't a real-time collector, but on a reasonably low-end computer (350MHz PII) running applications with average memory requirements (total ~50MB in objects of around 100 bytes - 2K in size) delay times were minimal (around 10ms, which I arranged to occur after event processing when it was found that no new event was waiting, hence was rarely detected by the user). You can use any type you want with it -- there are at least three different approaches:
* Make your classes inherit from a 'gc' base class
* Use a placement new operator (e.g. "new (GC) MyObject;" or "new (PointerFreeGC) char[16384];")
* Use the provided 'malloc' replacement library to replace all dynamic memory allocations with a GC allocation.
I chose to go the second route, because it gave me the most control. I had to spend a little time debugging problems caused by forgetting to include the (GC), but certainly less than I would have spent debugging undeleted objects had I not used the collector.
"Finally, there is a motion to include garbage collection in the C++ language. "
Call me old-fashioned, but I hope that's one that they will throw in the garbage. Call it something else if you're going to have garbage collection as an integral part. As a set of libraries, or as a compiler-time switch, fine - but not as part of the core. That's not C++, that's D.
Kevin Smith on Prince
Huh? Where did you get that idea? The Boost libraries most definitely are intended for production use, in a wide variety of environments. From the home page:
Boost libraries are intended to be widely useful, and usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use.They do aim to define and refine libraries so that they may eventually be appropriate for standardization, but the *primary* purpose of the Boost libraries is to provide tools that working programmers need, to get their production work done.
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
If you can afford to make your app compile with mingw's gcc (or cygwin's gcc but mingw should be easier), then you may be able to use mudflap, which is a memory debugging system integrated into gcc. You just need to pass -fmudflap, and gcc will instrument the program at compilation time.
i ze-Options.html#Optimize-Optionsg ing (maybe slightly outdated)
One thing is that it used not to properly instrument some really basic C++ operation in gcc 4.1 (I don't remember what exactly, something like copy construction of an object containing pointers) and was reporting spurious leaks because of that. It may have been fixed in 4.2.
Search for "mudflap" in the following page: http://gcc.gnu.org/onlinedocs/gcc-4.2.0/gcc/Optim
As well as http://gcc.gnu.org/wiki/Mudflap%20Pointer%20Debug
Application Verifier comes in x86, ia64 and amd64 flavors.
This tool allows you to enable PageHeap for your process, which is heap corruption detection built into the OS heap implementation. Upon freeing a block of memory, PageHeap will break into your debugger spewing tracing that a block has been corrupted. It can also provide the call stack when the block was allocated. Newer heap validation features are available in progressively more recent OS releases.
Following MS tools are absolutely free:i nstallx86.mspx. Following article explains how to use it http://support.microsoft.com/kb/268343/en-us.d ebugstart.mspxo ws/appcompatibility/appverifier.mspx.
- Use umdh that is a part of the Debugging tools for windows to track memory leaks. http://www.microsoft.com/whdc/devtools/debugging/
- Whatever you do make sure you have proper symbols. Following article explains how to get symbols from MS symbol server. http://www.microsoft.com/whdc/devtools/debugging/
- Use paged heap to track all other issue like memory overruns, double free and all other sorts of heap corruption. http://www.microsoft.com/technet/prodtechnol/wind
- Please note that if you run you application with app verifier checks on you need to run it under a debugger. I would strongly suggest windbg or cdb instead of visual studio because it has extensions that would greatly help you to track down the issue ("!analyze -v" "!avrf" "!heap -p -a "). For more details see windbg help. If your application is a service then you might consider running your machine under kd, which would trap all unhandled exceptions and application verifier reports.
- Following link has a very good windbg tutorial http://www.codeproject.com/debug/windbg_part1.asp
That is all you need to debug any kind of heap issues.
GCC got TR1 support two weeks ago. MSVS got it two years ago. Look in stdext:: in MSVS2k5.
StoneCypher is Full of BS
You can also use the Boehm garbage collector as a leak checker. Rather than collecting garbage, it reports on (and, I *think*, frees) memory that was 'forgotten' without being properly released.
Let's hope that there's intelligent life somewhere out in space 'Cause there's bugger-all down here on Earth.
By definition it is both. It is important to remember that no candidate library may be admitted to C++ if it isn't production ready. The idea that Boost is not meant for production use suggests that you too might do well with a bit of catching up on the ol' intents-and-philosophies set.
StoneCypher is Full of BS
My understanding is that it will be opt-in. I think manual management will be the default.
They don't want to remove the old ways (including malloc/free). And they don't want to penalize people who don't use garbage collection. In other words, if you don't want to use garbage collection you won't be paying for it in code size/runtime.
But for them that do... It might be nice to offer it.
That example happened something like 5 or 6 years ago. Maybe try it on MSVC++ with CString?
No, not at all. The current C/C++ specifications permit compilers to transform code in ways that can interfere with a garbage collector. Fortunately compilers do not do that as often as they could, but it seems like something important that should be addressed.
See Hans' paper Simple Garbage-Collector Safety for details.
DNA just wants to be free...