Please create an account to participate in the Slashdot moderation system


Forgot your password?
Programming IT Technology

Memory Leaks 34

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:
  • use C++ (Score:2, Interesting)

    by mj6798 ( 514047 ) on Monday August 13, 2001 @09:16PM (#2135794)
    In C, this is a never ending battle. Even with Purify, you are going to spend lots of time introducing bugs, then tracking them down. If you must stick with C, consider using one of the C interpreters (EiC, cint, etc.). Machines have gotten fast enough that you can use them for debugging your code. Or stop worrying about it and just use the Boehm garbage collector as a garbage collector.

    I switched from C to C++ basically because I couldn't get Purify for Linux. C++ has allowed me to adopt clear, well-defined memory management strategies and automate various pointer checks. I hardly ever get memory leaks or pointer errors in my C++ code anymore.

    But no matter what you do in your own code, if you are using C or C++, you will always be exposed to numerous pointer bugs and leaks in library code. Most real-world C++ code commits the same memory allocation sins and has the same pointer bugs as real-world C code--people aren't taking sufficient advantage of C++'s smart pointer facilities (even STL is flawed in that way). Therefore, for multiprogrammer projects, I wouldn't use anything but Java or another safe language anymore.

  • by MadAndy ( 122592 ) on Monday August 13, 2001 @01:26AM (#2144454)
    One of the places I'm involved with doesn't use the standard malloc calls. Instead we use something more like:
    get_mem(ptr, size, "widget hash table")
    When debugging, get_mem keeps track of all allocs. At the end, just before the program shuts down the heap dump routine is called which lists all outstanding memory blocks along with the debug string so you can see where they were allocated.

    It's also often practical to call the dump routine at various points within the program and give the output a quick look-over or diff - it's amusing how often you can nip these problems in the bud this way.

    Also, if you get really desparate, change the get_mem routine to increment a global counter and tag that to the end of each allocation info block. If you keep a program debug log and log each allocation it makes it easy to see where a loose block was allocated - grab the unique ID from the dump and search the log file for it.

    A handy feature about this trick is that you use #define to define get_mem, so when you go to production you simply define it to malloc and throw the debug string away - no speed or size cost in the running program. In addition, it basically costs nothing except an hour or so to set it up in the first place. The catch is you have to use it religiously from the start of your project.

    A really simple trick, but it has saved me so much work!

  • Roll your own (Score:2, Interesting)

    by Ratbert42 ( 452340 ) on Thursday August 09, 2001 @05:59PM (#2147055)
    In college, I rolled my own wrapper for malloc(), free(), and array/pointer dereferences. A couple hours of coding that wrapper caught most of my memory leaks and seg faults. If I could do it when I was half-drunk and didn't know what I was doing, you've probably got a developer on staff who can handle it.
  • Free Beer? (Score:2, Interesting)

    by Ratbert42 ( 452340 ) on Thursday August 09, 2001 @09:24AM (#2151254)

    A free (perhaps GPLd) clone would be so interesting; Rational's licensing is killing my current budget.

    Maybe you should put a developer or two on that project and see how long it takes them to build something similar. I think Purify runs about $1,500 now (could be wrong). That's what, two Aeron chairs? That shouldn't kill any real company's budget. Numega's Boundschecker is a viable cheaper alternative though. Or just rip off the free trial versions.

    When I've seen Purify bought, a developer downloaded the trial and built a list of all the problems he found and fixed using it. When he showed his manager how much pain and suffering the product could save it was an easy sell. (The hardest part was countering the "so everything's fixed already?" mentality.)

  • by Anonymous Coward on Friday August 10, 2001 @06:20PM (#2153487)
    Interesting - I had the same idea for a hardware implementation, where each index register would store the bounds. The operation "restrict to tighter bounds" is allowed, while the operation "expand bounds" is not. So the kernel begins with a single pointer to all RAM, and then gives pointers to the user-mode code which point to subsections. It's not even much extra silicon, although a pointer becomes 96 bits!

Counting in binary is just like counting in decimal -- if you are all thumbs. -- Glaser and Way