Forgot your password?
typodupeerror
Programming IT Technology

Memory Leaks 34

Posted by michael
from the bloatware dept.
G3ck0G33k writes: "Is there any free software version/clone of Rational's programs PureCoverage and/or Purify? I have worked with both of them on fairly large projects (>150,000 lines of code) and they were great to work with. When the first runs of Purify found nearly fifty instances of minor memory leaks, I was deeply frustrated/impressed. A free (perhaps GPLd) clone would be so interesting; Rational's licensing is killing my current budget. Of course, the more kinds of leaks it may detect, the better. GeckoGeek" We had a similar question last year but there's no harm in seeing what the current answers are.
This discussion has been archived. No new comments can be posted.

Memory Leaks

Comments Filter:
  • by Lumpish Scholar (17107) on Friday August 10, 2001 @12:04PM (#2114924) Homepage Journal
    For the other kinds of stuff Purify does (aside from memory leaks), look at Greg McGary's bounded pointer [gnu.org] work.

    Bad news: You'll have to build your own gcc (Greg's changes haven't yet been accepted in to the gcc trunk), and all your libraries (just as Purify re-writes all your libraries).

    Good news: The resulting code is much faster than Purify'ed code, and finds some problems Purify doesn't. I know of a major software development effort (hundreds of developers, millions of lines of code; sorry, can't give details) that uses bounded pointers to great advantage.

    Other tools: GNU Checker, dbmalloc, Bruce Perens' Electric Fence, MemProf, mpatrol, and Mprof; Google searches will turn them all up.
  • by pthisis (27352) on Thursday August 09, 2001 @01:52PM (#2118340) Homepage Journal

    The Boehm-Weiser garbage-collecting malloc() can be built in a leak-detection mode. Every time an object is leaked, it prints out the address of the memory in question. Do that. Then it's 15 lines of python to correlate that back with the malloc() calls; I wrapped malloc/realloc to print out the line number and filename, e.g.

    void *our_malloc(size_t howbig, int line, char * file)
    {
    void *p;

    p=GC_malloc(howbig);
    fprintf(stderr, "Line %d of %s/%s(): %p\n", line, file, p);
    return p;
    }
    #define malloc(x) our_malloc(x, __LINE__, __FILE__)

    with similar for realloc (and make free do GC_free).

    Then run the proggy, redirecting stderr through a simple python script: (leading spaces have been replaced with underscores since slashdot doesn't do PRE)

    import sys

    a={}

    for line in sys.stdin.readlines():
    __line=line.strip()
    __num=line[line.find("0x"):]
    __try:
    ____num=num[0: num.index(" ")]
    __except:
    ____pass

    __if line[1]=="i":
    ____a[num]=line
    __else:
    ____print "Leaked object: "+a[num]

    When I run my program this way I get the following output:

    Leaked object: Line 43 of leak_stuff.c/(): 0x806efe0
    Leaked object: Line 43 of leak_stuff.c/(): 0x806eff0
    Leaked object: Line 55 of leak_stuff.c/(): 0x806dfd8

    Which tells me which lines to look for the initial allocations of leaked objects at.

    The garbage-collecting malloc is really cool; it's at:

    http://www.hpl.hp.com/personal/Hans_Boehm/gc/

    for now, but rumor has it that gcc will become the official source for it at some point (it's needed for the Java compiler).

    Sumner

  • ccmalloc (Score:1, Informative)

    by Anonymous Coward on Saturday August 11, 2001 @07:14PM (#2120027)
    I went through this phase of trying to fix up the memory of all the code I'd ever written. I found ccmalloc [inf.ethz.ch] to be the best. Its the easiest, instead of gcc -o prog prog.o you just prefix with ccmalloc eg. ccmalloc gcc -o prog prog.o. It provides a nicely formatted output log file, with configurable filtering, showing the stack trace of each unfreed leak, and also catches over/underflows, and lots of other stuff. hint: if you are using the c++ std library get g++-3 (with libstdc++-3) and #define __USE_MALLOC to disable malloc pooling. RPMs here [rpmfind.net]
  • by pthisis (27352) on Friday August 10, 2001 @11:41AM (#2122452) Homepage Journal
    Be careful using Boehm in production code; the web pages has the caveat:

    C compilers may not hide pointers in the generated object code. In our experience, standard commercial compilers obey this restriction in unoptimized code. Most aggressive optimizing compilers do not obey this restriction for all optimized code. For details and examples see papers/pldi96.ps.gz. However, it is difficult to construct examples for which they violate it, especially for single-threaded code. In our experience, the only examples we have found of a failure with the current collector, even in multi-threaded code, were contrived.

    However, the gcc developers claim the gcc does in fact violate this constraint. So using Boehm gc with gcc may not be safe in production code. The gcc mailing list has had a couple of threads on how to make gcc garbage-collector friendly in the future (once again, Java is one impetus for this). Until then, I'd stick to manual mm and use the gc only to help find leaks.

    Sumner

  • by spacewhale (253229) on Friday August 10, 2001 @02:05AM (#2125915)
    Write a malloc wrapper and #define it in place of the real thing. With #define you can easily log the location in the code, amount of RAM, and location in memory to a file, then write a script in the language of your choice to see which locations in RAM weren't dealloced, and match them with the appropriate malloc call, which also contains the location in code. It took me about an hour to implement this in a multi-thousand line program and it works very well. The only thing it doesn't catch is when a library call mallocs something and expects you to dealloc it, but i solved this by including a fake malloc call that just logs but doesn't actually malloc, so you'd call it right after the library call that actually does the malloc.
  • by epperly (188343) on Friday August 10, 2001 @11:34AM (#2129544)

    I like dmalloc [dmalloc.com] for memory debugging. It even found a memory bug for a program that purify choked on. It doesn't have a GUI.

  • by szomb (318129) on Friday August 10, 2001 @09:19AM (#2141376)
    ElectricFence detects overruns of malloc()d buffers (hence its name). Unless this changed recently I am fairly sure it has nothing to do with leak detection?
  • MEMPROF (Score:3, Informative)

    by kijiki (16916) on Thursday August 09, 2001 @02:47PM (#2151318) Homepage
    Its by one of the RHAD labs kids. Its basically just a GUI around bohem's garbage collector in leak-detector mode.

    Its not purify (it really aims for leak detection, not all the other errors purify finds), but the efence + memprof combination gets you about 85% of purify's functionality.

    It seems to handle threaded apps reasonably well, and C++ doesn't faze it. The only down side is that its hard to get running on non-x86 platforms.
  • Checker (Score:2, Informative)

    by anaymouse (513946) on Thursday August 09, 2001 @05:58PM (#2158606) Homepage
    Try Checker [gnu.org] I think AX.25 pointed to some relevant information, but was moded has redundant for some odd reason.
  • by d^2b (34992) on Thursday August 09, 2001 @10:41PM (#2169884) Homepage
    dmalloc (www.dmalloc.com) seems to work pretty well for finding memory leaks. It is distributed under a BSDish
    license.

    Compiles and runs out of the box on an alpha
    running Linux.

    GUI? uh no. It has a nifty command line utility to control logging etc...

  • mpatrol (Score:2, Informative)

    by brianmed (131838) on Sunday August 19, 2001 @12:54AM (#2174296)
    mpatrol is another tool to help with this.

    It can:
    - log your memory usage
    - report on improper memory usage
    - profile your memory usage
    - work with your applications *without* re-linking (assuming your OS allows this)

    The web page is at:

    http://www.cbmamiga.demon.co.uk/mpatrol/

    In addition, the author has excellent documentation. The pdf manual actually has a section that lists competing products and what they do.

    http://www.cbmamiga.demon.co.uk/mpatrol/files/mp at rol.pdf

10 to the 12th power microphones = 1 Megaphone

Working...