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.

Use garbage collection

[WanderingGhost]

If you're woried about memory allocation, use garbage collection:
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_so urce

And contrary to what you may think, it's qiute easy to use:

variable = new (GC) my_class;

Or even easier: make your classes derived from gc.

In C, you just replace malloc.

And I have found that there is no slowdown wen using a garbage collector. It's nice, and keeps the code clean. Try it someday.

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

[Rob Kaper]

Hi. KDE developer here. We've checked developer.kde.org (the machine hosting Valgrind) and the md5sums. So far this looks like a hoax, so please move on. We will stay on the alert and continue investigating, but to quote one of my favourite authors: don't panic.

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):

Correct md5sum

[Anonymous Coward]

Hi,

I have just verified that we have no evidence of
a backdoor in valgrind.
This is the correct md5sum
76c59f7f9c57ca78d733bd956b4d94ae valgrind-1.0.0.tar.bz2

I will put this information also online on
http://www.kde.org/md5sums/valgrind-1.0.0.tar. bz2. md5sum

So you can check this information via a second channel.

Yours,
-- martin
P.S.: The AC claims incorrectly that exact the above md5sum indicates a compromised archive which is plain wrong!

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. :)

Wow, Debian version already updated

[Anonymous Coward]

1.0 is available in unstable.

Cool.

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:Any reviews?

[Anonymous Coward]

valgrind seems faster? bullshit! It's implemented as an x86 emulator (*cough* bochs *cough*). It slows down code by 20-50x.

Re:Market for commercial programming tools for Lin

[movement]

Here's some suggestions :

1) don't charge such an absurdly large price
for software mostly built on free software
(Mikael's perfctr)

2) accept that when you have competition that
is free software, it's gonna beat you.

[Disclaimer: I am indeed the lead developer for
your competition]

Of course you can just avoid those errors...

[voodoo1man]

For most applications, it just makes better sense to avoid these errors altogether by using a good garbage collector.

An excellent implementation is the Boehm-Demers-Weiser (commonly referred to as just "Boehm gc") conservative gc. It can be used for C/C++, and is highly portable. It's a real-time, non-compacting (so you still get heap fragmentation like managing memory by hand, but the collection time is shorter and it's more portable), and uses a conservative mark-sweep algorithm (briefly, treats anything that looks like a pointer as a pointer, to avoid costly checks or increase portability in the case of C/C++.)

For a moderately large amount of garbage, the incremental collection pauses take less than about 5-10 milliseconds (hence why it's a real-time collector) on a PIII-500, the algorithm scales fairly well, and it's suitable for all but the most time-critical (anything video related) or memory-thrashing (I really don't know of any app that needs to be) programs. GC will speed up development time tremendously, and can eliminate segmentation faults and memory leaks for most programs. I really don't understand why more projects don't use it.

That being said, Valgrind does seem extremely useful for projects that do need to allocate memory manually. It looks very convenient to use, and the thoroughness of the checks is impressive. The implementation does seem a little uncomfortable to me - it's certainly a lot of effort to write a whole virtual machine just for the task! The portability prospects aren't appealing either.

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.

Re:Any reviews?

[Sanga]

# Purify makes it easier to disable errors/warnings from libraries out of your scope.

Details about Valgrind suppressions at:
http://developer.kde.org/~sewardj/docs/manual .html #suppfiles