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

Re:BACKDOOR in Valgrind - Please Read

[michael]

Please don't feed the trolls. All the posts claiming a backdoor in Valgrind and supposedly responding to each other ("Hey, I found it too!" "Me too!" "Here's what I got!") were all posted by the same person.

Re:Any reviews?

[Charles Kerr]

I've been using Valgrind on Pan, which is multithreaded, and it works fine. Maybe given more time I'll find features that I miss from Purify, but for now I'm very happy.

Things I like better in Valgrind:

• Valgrind works on Linux.
• Valgrind doesn't require instrumenting each object file and library at build time. (This is a biggie)
• Valgrind's run-time options are more flexible.
• Valgrind works with both gcc 2 and 3.
• Valgrind seems to run faster than Purify. (Different hardware and OSes, so this is a guess.)
• Valgrind doesn't have a Motif GUI. ;)
• Valgrind doesn't have an insane, broken license manager.
• Valgrind's technical support is better. (Yes, I've dealt with both.)
• Valgrind doesn't cost $2,364 per seat.

Things I like better in Purify:

• Purify can handle static libraries.
• Purify makes it easier to disable errors/warnings from libraries out of your scope.
• Valgrind doesn't work on Solaris, so I'm stuck with Purify for my day job. :)

Re:Strangeness

[Charles Kerr]

I know I shouldn't feed the trolls, but just for fun:

(18:14:38)(~/src/valgrind-1.0.0): grep open vg_scheduler.c
(18:14:45)(~/src/valgrind-1.0.0): grep 11 vg_scheduler.c
02111-1307, USA.
(18:14:52)(~/src/valgrind-1.0.0):

Re:Strangeness

[rjh]

I've just grepped through vg_scheduler.c looking for `bind', `sock', `11', `RAW', `raw', and several others. I've come up with absolutely nothing. Admittedly, I haven't checked out the entire source--at 3500 lines, it'd take me several days to do a proper audit--but so far I haven't found any references to socket calls anywhere.

Still, I would appreciate it if the maintainer could check out vg_scheduler.c and see if there's something amiss there. Thanks. :)

Re:Valgrid is not as complete as Purify

[mce]

When I called Rational to ask if they planned on supporting Linux, they said "Maybe sometime in the future", but when I continued questioning them, they said they had no immediate plans to start working on Linux versions of any of their software.

Franckly, I have the impression that Rational regard Purify and Quantify as cash cows that should not be touched unless absolutely required. All they ever did since they bought them was:

• implement a Windows version (there's more cash at hand in that world);
• change the licensing scheme to be ever more annoying;
• fix minor annoyances after HP or Sun released new compiler versions;
• finally add gcc support for version 2.95 when 3.0 had already been released for some time.

Other than the gcc 2.95 thing, I have seen no real improvements in years (I don't use Windows). Over the years, we forked over a lot of money for "support", though.

It's a great tool, but I'm not impressed with the company behind it.

Re:Valgrid is not as complete as Purify

[leob]

There are two important features of Purify that are most notably absent in valgrind:
- the ability to specify user's memory allocators/deallocators (it is mentioned in the documentation, though)
- the ability to detect array bound violations (Purify's ABR/ABW).

You decide which of the two is more important for you.

Re:Valgrid is not as complete as Purify

[jelle]

IIRC purify also doesn't guarantee to catch all oob accesses, so they probably use a similar technique.