Slashdot Mirror


What Memory Leak Detector Do People Use?

funnymalloc asks: "A quick search for 'leak' on FreshMeat yields a whole slew of projects/products which claim to help one find and kill memory bugs of various types when using C/C++. ccmalloc, debauch, dmalloc, LeakTracer, libyama, MCheck, MemProf, memwatch and mpr show up on the first page alone. Ideally a product would detect all of the common problems: array over/under runs, write to unallocated memory, write to 'freed' memory, unfreed memory (a leak) etc. And would work with both new/delete and (m)(c)(re)alloc/free. My question is which of these projects/products do people use and like? (and no, Java is not an answer)"

3 of 29 comments (clear)

  1. Java is not the answer... by DeadSea · · Score: 5
    When you say that Java is not the answer, you are more right than you may know.

    Java does a wonderful job with the simple stuff that you mention. It checks array bounds, does not let you write to unallocated or freed memory, and a slew of other runtime checks. Java however does not eliminate memory leaks.

    To be able to be freed (by the garbage collector) an object must have no references. Accidentally keeping references around is a lot easier than you might think and can be a huge source of memory leakage.

    Dr. Dobb's has an article about this.

    I love Java and I prefer using it for most of my projects, however anybody who tells you that it solves all your memory leak problems is blowing smoke out their ass.

  2. Just did some research by reverse+solidus · · Score: 4

    I used ElectricFence, mainly because I happened to already have it installed. It helped. There are a bunch of others, some of them look interesting:

    MallocDebug
    Thu Dec 21 13:26:01 CST 2000 - overview of malloc debugging
    tools. looks good.

    mpatrol
    Thu Dec 21 13:37:30 CST 2000 - didn't try it out,
    but the documentation actually lists
    "related software", which indicates to me they did their
    reseach.

    glibc builtin
    Thu Dec 21 13:43:54 CST 2000 - evidently glibc has debugging
    stuff built-in.

  3. No, but it's DAMN good. by brad.hill · · Score: 4
    What you say is true, but in my experience working on a relatively large Java project with over a dozen developers with very little C and Java experience, we give almost zero attention to memory management issues. We have a large servlet application that we run hundreds of thousands of transactions through with no appreciable growth in memory usage, so it's not like we just ignore problems; I can confidently say there aren't any of any consequence.

    Pretty much the only place we have to care about resource and reference cleanup is with JDBC. Those instances when we have had problems (always with JDBC ResultSets not being closed), a $500 tool called OptimizeIt has been able to show us what line of code caused the problem with less than five minutes of total time devoted to the problem.

    So, while Java is not perfect, in my experience it cuts down by 99% the total amount of time and effort you have to devote to memory related issues. With a dozen Java newbie developers adding 60,000 lines of code to an application over a year period, as the lead programmer who deals with such problems, I've spent two hours on memory management issues. No memory checking tool for C and C++ do that.