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

8 of 398 comments (clear)

  1. um by Anonymous Coward · · Score: 5, Informative

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

  2. Fluid Studio's Memory Manager (MMGR) by Rezonant · · Score: 5, Interesting

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

  3. Re:two points by Anonymous Coward · · Score: 5, Informative

    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

  4. Valgrind by bms20 · · Score: 5, Informative

    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

  5. Re:Boost? Ugh by pzs · · Score: 5, Interesting

    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

  6. Most people can't understand Purify's output by Anonymous Coward · · Score: 5, Insightful
    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.
  7. Don't allocate or free = no leaks = need no tools by seniorcoder · · Score: 5, Insightful

    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.

  8. Re:I've used... by inviolet · · Score: 5, Funny

    Memory checkers? GARBAGE COLLECTORS?! Have you no HONOR?!

    We are KLINGON. We need no checkers. We need no garbage collectors. We need none of these weak HUMAN facilities. We write our CODE from the COMMAND LINE:

    > COPY CON DECAPITATOR.EXE
    [Alt+077] [ALT+090] . . .

    --
    FATMOUSE + YOU = FATMOUSE