Valgrind 1.0.0 Released

Anonymous Lazy Boy writes "Yesterday saw the official release of Valgrind 1.0.0. Valgrind is a C/C++ programmer's dream come true: effortless memory allocation checking, uninitialized memory access, leaks etc. Purify for Linux has arrived, only better: contrary to its commercial (non-Linux) sibling, checking is performed directly on the executable, no re-linking necessary. The technology behind Valgrind is highly fascinating and explained down to the very gory details in the documentation."

Comments

Any reviews?

[ergo98]

One thing I've found with automated QA products is that usually they have critical faults that prevent them from being realistically useful (for instance many of them grind to a halt or give false positives in multithreaded apps). How's this product for real world use? (And no this isn't a "Read the Article!" question...the article is like a press release and hence doesn't answer my question).

Re:Any reviews?

[Charles Kerr]

On a Pentium 450 running Limbo, I can start up Pan 0.12.91 with valgrind --num-callers=16 --leak-check=yes --leak-resolution=med in one minute, nine seconds. On an otherwise-idle Sparc Ultra 10 running Solaris 7, it takes Pan built with "purify -chain-length=7 -cache-dir=/tmp -always-use-cache-dir=yes" more than 15 minutes to start up, with the CPU pegged at 100% the entire time.

If there's a secret "Don't Run Slow" switch to Purify, let me know what it is.

An excellent tool

[alriddoch]

Valgrind really is an amazing bit of software. Working on large application which use many different libraries it becomes harder and harder to work out where those bugs are, and all the free tools I have tried so far have done a very poor job of finding them. I have now been using valgrind for several months, and got 1.0 straight from the author by mail having reported a few bugs in earlier versions. It speeds up finding those hard to reproduce bugs, and often shows up memory errors which you didn't even know were there. It is also excellent for detecting memory leaks as it knows the difference between memory that has been genuinly leaked, and memory which is not freed, but still has a reference to it stored when the program exits. All the software I work on is now much more robust than it was a few months ago, and much of this I can put down to valgrind being available. This is the only free tool that comes close to the commercial tools like Purify, and in many ways it is superior to some of the expensive high end tools. The author is extremely responsive and helpful, and has been developing valgrind full time self funded.

Re:Use garbage collection

[p3d0]

You really really wouldn't want to write an operating system with C++, much less with GC.

Bull.

Be was written in C++, and so is K42, IBM's next big massively scalable Linux-compatible kernel. Some of the smartest people I have ever met work on K42, and these guys know C++.

Also, GC doesn't necessarily add any overhead to programs: it depends on memory usage patterns, but clearly, being forced to free everything chunk-by-chunk as it's no longer needed can't always be the most efficient policy. (Otherwise, why do program call stacks use special-purpose storage management instead of the heap?)

Having said that, it is true that a conservative collector is not suitable for all memory allocation needs.