Please create an account to participate in the Slashdot moderation system


Forgot your password?
Programming IT Technology

Memory Checker Tools For C++? 398

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 discussion has been archived. No new comments can be posted.

Memory Checker Tools For C++?

Comments Filter:
  • um (Score:5, Informative)

    by Anonymous Coward on Wednesday June 06, 2007 @05:45AM (#19408479)
    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).
    • Re: (Score:3, Informative)

      by RegularFry ( 137639 )
      It's an alternative to needing a memory checker, though, so it would provide an valid solution to the problem for a new application.
    • Re:um (Score:4, Insightful)

      by Shadowlion ( 18254 ) on Wednesday June 06, 2007 @08:23AM (#19409237) Homepage
      > and works fine in legacy apps

      Regarding legacy applications, I think the point was that he can't go back through the app and rewrite everything to use smart_ptr.
  • two points (Score:4, Interesting)

    by sentientbrendan ( 316150 ) on Wednesday June 06, 2007 @05:49AM (#19408497)
    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?
    • Re:two points (Score:5, Informative)

      by Anonymous Coward on Wednesday June 06, 2007 @05:52AM (#19408509)
      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.

    • Re:two points (Score:4, Informative)

      by Anonymous Coward on Wednesday June 06, 2007 @06:02AM (#19408567)
      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).

      • Re:two points (Score:4, Interesting)

        by shutdown -p now ( 807394 ) on Wednesday June 06, 2007 @08:28AM (#19409263) Journal

        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 (Score:5, Insightful)

          by Anonymous Brave Guy ( 457657 ) on Wednesday June 06, 2007 @01:15PM (#19413093)

          It's not automatically bad, but using semi-automated memory management like this tends to reduce the emphasis on constructing things only when they're needed and destroying them immediately when you're done with them. This concern, known as "Java bloat syndrome" in honour of the language that first popularised it, can lead to major performance problems in applications that manipulate a lot of data, and is a favourite mistake made by the cult of "hardware is cheap, so optimisation doesn't matter".

          The thing is, this sort of care-free programming philosophy is natural in languages like Java, so languages like Java have had to learn from their early mistakes and adapt. There have been dramatic improvements in GC technology since those early days, and today there isn't the same degree of performance penalty associated with relying on GC to clear everything up.

          However, this sort of behind-the-scenes magic isn't really the "C++ way". You can do it, but tools like shared_ptr don't have the same level of sophistication as full-blown GC. Using them requires some care from programmers, and as the grandparent post said, this can lead to problems if the programmers come to rely on them more than they ought.

          FWIW, I'm not sure I'd have described things in quite such black-and-white terms as the GP, but I can see the underlying point and I think it's a valid one.

          • Re:two points (Score:4, Insightful)

            by shutdown -p now ( 807394 ) on Thursday June 07, 2007 @01:45AM (#19420617) Journal
            In other words, programmers shouldn't use shared_ptr as if it were a replacement for GC. When it is worded thus, I can fully agree with that (and indeed, anyone who understands how reference counting works, will agree as well). The nice thing about shared_ptr is that, unlike GC, it is still fully deterministic, and so it properly preserves the "C++ spirit".
      • Re:two points (Score:5, Informative)

        by d00ber ( 707098 ) on Wednesday June 06, 2007 @09:48AM (#19409943) Journal
        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.
    • Re: (Score:3, Informative)

      by master_p ( 608214 )
      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).
    • Re:two points (Score:4, Interesting)

      by Craig Ringer ( 302899 ) on Wednesday June 06, 2007 @09:07AM (#19409549) Homepage Journal
      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).

    • Re: (Score:3, Informative)

      by julesh ( 229690 )
      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 colle
    • Re: (Score:3, Informative)

      by akeru ( 15942 )
      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.
  • by grusin ( 1112113 )
    Some time ago i was using valgrind, but afaik it does not run under windows. I think that MS Dev has some memory leak detection built in, but it is far behind valgrind. Besides, who codes stable stuff for windows? :)
    • Re:I've used... (Score:5, Informative)

      by TapeCutter ( 624760 ) on Wednesday June 06, 2007 @06:52AM (#19408805) Journal
      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.
  • by Rezonant ( 775417 ) on Wednesday June 06, 2007 @05:51AM (#19408505)
    Yep, Paul Nettle's little memory manager rocks. It WILL find leaks in your program. [] (Yes, you have to navigate through a horrible flash site to get it, but it's worth it).
  • valgrind, libgc (Score:2, Informative)

    by Anonymous Coward
    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 [] which tends to do the job. Haven't used it, though projects like Mono [] use it extensively.
  • Purify (Score:2, Informative)

    by Anonymous Coward
    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)
    • by Anonymous Coward
      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.
    • Re: (Score:3, Interesting)

      by 0123456 ( 636235 )
      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.
  • STLPort (Score:4, Informative)

    by kazade84 ( 1078337 ) on Wednesday June 06, 2007 @05:58AM (#19408541)
    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.
    • Everyone includes such a debug mode, including Visual C++ and g++. In my opinion both g++'s and visual C++'s are suprior to the one found in STLport. However, it won't really help you find memory leaks, only corruption from the standard containers.
  • by DrXym ( 126579 ) on Wednesday June 06, 2007 @05:59AM (#19408549)
    I've played with Boundschecker, Purify (& Quantify) and Fortify. My experience of these tools is that they either take a painfully long time to run, throw up too many spurious warnings or crash outright after eating all available memory / disk space.

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

    It's hard to say what you can do except foster safe coding practice and highlight the common pitfalls such as memory leaks, buffer overflows etc. Many compilers can help detect heap / memory overruns because the debug libs put guard bytes on the stack & heap that trigger exceptions when something bad happens. There are also 3rd party libs such as Boehm [] which help with memory leeak / garbage collection issues and dump stats. I'd say using STL & Boost is also a very good way of minimizing errors too simply because doing so avoids having to write your own implementations of arrays, strings etc. which are bound to be less stable.

    • Re: (Score:3, Interesting)

      by cerberusss ( 660701 )

      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.
      • by tepples ( 727027 )

        So my philosophy is to chop programs up in different processes.
        I'd like to see details of how you would apply your approach. How would you propose that the program "Mozilla Firefox web browser" be chopped up into processes?
        • Hehheh you got me there, however I got from the parent that he was talking about a monolithic piece of business software. I.e. backend stuff. We're currently doing a project where we read measurement data from one or more instruments and functions are split up into processes. So we have one daemon for reading out one particular instrument, one process for the plotting backend, one for archiving data, et cetera.
    • Re: (Score:2, Insightful)

      by gladish ( 982899 )
      This is a result of the way that most people are developing code. They build some huge app and then finally realize that it doesn't work because it's riddled with defects and memory leaks. What should have been taking place is the creation of small units tests which were then run under some runtime analyzer like pruify. With that said, I've used purify, insure++, and valgrind. I found insure++ to be the best. I will admint that the code runs much more slowly but I was amazed at the stuff that it found. I've
    • Re: (Score:2, Interesting)

      by ShakaUVM ( 157947 )
      >> 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 legac
      • Re: (Score:3, Insightful)

        by peterpi ( 585134 )
        I love this comment, from Bjarne Stroustrup's home page (href= l #memory-leaks [])

        Q) How do I deal with memory leaks?

        A) By writing code that doesn't have any. (goes on to advocate vector & string)

        And also: C++ Is my favorite garbage collected language because it generates so little garbage ( y-say-that [])

        Over the past 6 months or so, I've really made an effort to better my usage of C++ (using Effective C++, Effective
    • by Anonymous Coward on Wednesday June 06, 2007 @08:51AM (#19409417)
      Most people can't understand Purify's output, and I've actually ran across coders who actually believe their code can't be as bad a Purify says it is.

      For example, this code has serious issues:

      extern string method_that_returns_string_object();
      char *ptr;
      ptr = method_that_returns_string_object();
            . .
      That actually will compile, and seem to "work". But it's horribly wrong, and Purify will find the problems.

      And FWIW, I've used Purify on massive apps, and found huge problems that the developers didn't even know were there. On one project, they couldn't explain why their "perfect" app kept crashing, either. Worse for them, I had been hired as a consultant to fix their problems that they couldn't seem believe existed (HINT: your boss hired someone from the outside...), and after watching the team flail and spend literally almost a man-year trying to find one memory bug, I finally had enough of "advice giving" being ignored and got on their system, linked their app under Purify, ran it, and found the bug - a double delete of an object from two different threads. It all took me about fifteen minutes. I did that in front of their management. I made my point.

      Purify (and like tools) are a great help. Not using them is like trying to build a house without power tools. Yeah, it can be done. But what would you think if hired a builder to make your house and his team showed up carrying hand saws? Oh, and you are paying that team to hand-saw all the lumber...

      What would you think of that builder?

      Yet, when a developer asks for tools like Purify, management often balks. Because 1) they're shortsighted, and 2) developers don't know how to use such tools.

      Like I said - what would you think of a construction company where the workers don't know how to use modern power tools to help their productivity?

      Well, you just put yourself in that category.

      Yes, Purify is somewhat slower than running without Purify. But it's a lot faster than most other full-memory checking methods. If you're worried about speed, link against the Win32 debug libraries - they'll at least show problems with double free() calls, access of free()'d and deleted objects, etc. And without too much performance problems.
  • Boost? Ugh (Score:3, Interesting)

    by Viol8 ( 599362 ) on Wednesday June 06, 2007 @06:01AM (#19408559) Homepage
    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 (Score:5, Interesting)

      by pzs ( 857406 ) on Wednesday June 06, 2007 @06:10AM (#19408603)
      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.

      • Re: (Score:3, Informative)

        by Cyberax ( 705495 )
        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.
      • Re: (Score:2, Informative)

        by rabidgnat ( 923944 )
        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
      • Re: (Score:2, Interesting)

        by MikeTheMan ( 944825 )
        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 in
        • Re: (Score:3, Insightful)

          by pzs ( 857406 )
          Amen, brother.

          The only thing I can add to this is that an error message that only takes up 8 lines is a cissy error coming from BGL. I had errors that were multiple screenfuls. It seems somehow wrong when a tiny type error that can be fixed with maybe 3 or 4 well placed characters can be so verbose. I guess that's C++ for you.

      • Re: (Score:2, Interesting)

        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: (Score:3, Informative)

          by swillden ( 191260 ) *

          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.

          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.

    • Re: (Score:2, Insightful)

      by kazade84 ( 1078337 )
      If you wanna "get the job done" then boost is sometimes exactly what you need. I'm not saying that you should memorize the whole library but sometimes a boost library is available for what you want to do. I couldn't live without boost::lexical_cast, boost::shared_ptr, boost::tokenizer and boost::python is genius. You *could* write all of those things yourself but honestly, why?

      If you wanna code in C++ then you'd better get used to the "weird syntax" of templates and especially the boost libraries, they ARE
      • Re:Boost? Ugh (Score:5, Insightful)

        by Viol8 ( 599362 ) on Wednesday June 06, 2007 @06:28AM (#19408693) Homepage
        "you'd better get used to the "weird syntax" of templates and especially the boost libraries"

        I'm used to templates syntax (though I think its ugly and Stroustrup could have done a lot better) but Boost makes it worse by overloading operators and then using them in ways never intended that produce syntax that a plain C++ wouldn't even recognise, never mind understand what its the gratiutous overload of () for matrix ops where a simple function call would have been much cleaner and easier to follow.
        • Re: (Score:3, Interesting)

          by N7DR ( 536428 )
          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

    • Re: (Score:2, Informative)

      by oergiR ( 992541 )
      You are misinformed. You probably don't have any experience with Boost, nor do you get your facts right. Boost consists of different parts, and for using boost::shared_ptr you need only a couple of headers. There is even a tool that extracts the necessary bits for you [].

      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.

      boost::shared_ptr has been in standard library implementations for a couple of years now as std::tr1::shared_ptr. It will most likely be included in the next C++ standard []. Apparently the C++ standard committee did think that shared_ptr solve

      • by Viol8 ( 599362 )
        "Apparently the C++ standard committee"

        Ah yes , the C++ commitee. The people who turned C++ from a learn OO version of C into the bloated mess we have today. Sorry , but they're hardly a name to drop in an argument to bolster your case.
        • by ardor ( 673957 )
          Correction: the people who gave C++ templates, which are a killer feature. Thanks to templates, I can do generic programming and metaprogramming in C++, which are orders of magnitude more powerful than OO only.

          No, Java generics are not the same.
    • by Pretor ( 2506 )
      You must be kidding. Have you actually tried to use boost for more than a second? You only have to use the parts of boost that you need. It's not that you have to link or include every boost library for you application. I've been using boost professionally for several years. And it really makes coding in C++ a lot nicer. Please note that you need a modern compiler like G++ > 3 or Visual C++ 2005. Otherwise you'll have to play with the compatible syntax which is horrible.

      Here are some of the parts that we
  • by Photo_Nut ( 676334 ) on Wednesday June 06, 2007 @06:04AM (#19408581)
    PageHeap is a debugging tool for Windows created by Microsoft. It does what you want.

    For more information look here: []
  • Valgrind (Score:5, Informative)

    by bms20 ( 827647 ) on Wednesday June 06, 2007 @06:06AM (#19408593)
    Use valgrind : 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
    • Re: (Score:3, Informative)

      by HRogge ( 973545 )
      If you still think Java/C# are slow, especially in terms of memory management you might want to read this: tp09275.html []
    • Re: (Score:3, Interesting)

      by DrXym ( 126579 )
      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

    • Valgrind's default memcheck tool is an excellent way of finding memory errors - ranging from extremely subtle to obvious. In addition, Valgrind can be used as a code profiler, cache simulator and many other things. It really is an excellent tool - I recommend it to anybody writing C++.
      • Valgrind is, by far, one of the most useful tools i've ever came across for C/C++ developing. It's a shame it runs only on Linux - i bet a lot of Windows software would be much less leak-proof if such an excellent (and free) tool were available for them.
    • Re: (Score:3, Informative)

      by Idaho ( 12907 )

      Use valgrind : 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.

      It's been a few years since I last programmed in C++, but Valgrind indeed really saved the day on a regular basis. Also look into (KDE-)frontends if you think looking at text output is not very convenient. Couldn't agree more with this part, it's the best tool I've seen - and it's free software, too.

      By the way, you're

    • Re:Valgrind (Score:4, Informative)

      by Rogerborg ( 306625 ) on Wednesday June 06, 2007 @10:00AM (#19410127) Homepage
      Agreed. I am not a fan of Linux development environments, but there really is nothing like Valgrind available for Windows, so run as much of your code as possible through Valgrind on Linux. I'd say that it is worth the effort, even if you have no intention of supporting a Linux distribution.
  • eFence (Score:4, Interesting)

    by cannonfodda ( 557893 ) on Wednesday June 06, 2007 @06:12AM (#19408613)
    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.
    • Programs run quickly under efence, but sadly memory use will balloon. It (I hope I have this right) puts each malloc into a separate page with guards either end. So every tiny strdup() will use some huge amount of your address space. It's not practical for anything bigger than rather small.

      valgrind takes the opposite approach: it does all the checking in software, so it runs slowly (about 1/20th of real speed, the last time I measured it), but is much more modest in the amount of RAM it needs (though it

  • Visual Leak Detector (Score:3, Interesting)

    by Tucano ( 1112131 ) on Wednesday June 06, 2007 @06:34AM (#19408721)
    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: r.asp []

    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.
  • I write C++ for embedded systems, and I needed a decent heap checker, so I rolled my own. It only took a few hours to write.

    Of course, I basically copied the mechanism of tools like efence or DUMA, but I was able to tweak the tool to do exactly what I needed it to do. You may want to try the same approach.

    • Re: (Score:3, Interesting)

      by Doctor Memory ( 6336 )
      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
  • by Tronster ( 25566 ) on Wednesday June 06, 2007 @08:07AM (#19409149) Homepage
    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.
  • by seniorcoder ( 586717 ) on Wednesday June 06, 2007 @09:19AM (#19409653)
    We are running many high speed financial message processing applications. A crash for any reason (including a leak) would be very costly for us.

    We pre-allocate pools of objects at startup and then re-use them. No other memory is allocated or freed while the process is running. Our pools of reusable objects are monitored very carefully as an object that isn't release back to its pool when the job is done is akin to a memory leak. Use of sentries to automatically release objects back to the pools when they fall out of scope is mandatory.

    So my answer is to the problem is:
    1. Use sentries (or some other mechanism) to guarantee memory is released.
    2. Don't allocate except at startup.
    3. No need for elaborate tools due to the above.

    I'm sure that not all applications data usage would fit into this model, but it is surprising how many can.

    We have seen some leaks in our applications. These were tracked down to STL internally leaking. They weren't generally very large and therefore we continue to live with them.

    On the subject of garbage collectors, some of our colleagues use Java and .NET. Both sets of colleagues have had major performance problems caused directly by the garbage collectors kicking in and consuming vast CPU power while they did their thing. The result was a failure to process messages in a timely manner in our high speed environment. The solution in both languages was to use pools of reusable objects and never cause their reference counts to drop to 0. Thus they implemented the very same mechanism that we use in C++ and avoided the garbage collectors.

    So don't think that a garbage collector is the solution. Perhaps in less demanding applications it is a potential answer.

    Lastly, I strongly dislike anything from Rational. I find them overpriced unreliable bloatware (YMMV). Purify used to be good some time ago, but those days are long gone.

    I echo what others have said above. You are a developer. You know your requirements. Build a simple tool to monitor and check your usage. For us it was managed pools of re-usable objects.
  • Memory Validator (Score:4, Informative)

    by sdt ( 7606 ) on Wednesday June 06, 2007 @09:30AM (#19409755) Homepage
    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.
  • by Heir Of The Mess ( 939658 ) on Wednesday June 06, 2007 @10:17AM (#19410327)
    Use a testing framework like Parasoft's CPP stuff uct=CppTest []
  • valgrind (Score:3, Interesting)

    by nanosquid ( 1074949 ) on Wednesday June 06, 2007 @10:24AM (#19410415)
    Use valgrind.
  • GCC mudflap (Score:3, Informative)

    by MORB ( 793798 ) on Wednesday June 06, 2007 @11:25AM (#19411273)
    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.

    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: ze-Options.html#Optimize-Options []
    As well as ing [] (maybe slightly outdated)
  • by cant_get_a_good_nick ( 172131 ) on Wednesday June 06, 2007 @12:11PM (#19412079)
    GLIBC allows you to create hooks for the standard mem functions (malloc/realloc/free). Remember that g++ still calls these under new/delete so it works for C++ also.

    One of our guys coded up a simple shared lib that can be loaded with LD_PRELOAD that sets simple hooks of printing memory locations for new/realloc/delete. He then wrote a perl script that kept track of these things and spit out anything that was malloc'ed and not realloc'ed or free'd.

    I can't post it, because technically it's not my code it's my company's. But his shared lib code is just 300 lines long, and shouldn't be hard to duplicate. The perl log filter is even more straighforward. Each malloc gets saved. Each free removes the malloc. Each realloc removes the old malloc and adds a new one. Anything left over is a leak.

    Override __malloc_initialize_hook with a pointer to your init_function. In your init_function, save the old functions at __malloc_hook __free_hook __memalign_hook and __realloc_hook and substitute your own. Now write your replacement functions, in it, do your logging and temporarily replce the old hooks and call the original functions, replace with your hook on the way out to get the next call. All of the hooks should be wrapped in a mutex to help re-entrancy problems.

    It's not a full memory detector, just does leaks, but it's non-intrusive, requires no recompiles, and is the best way we have to leak detect our huge server long running code.

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein