Valgrind 1.0.0 Released 301
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."
Re:BACKDOOR in Valgrind - Please Read (Score:4, Informative)
Use garbage collection (Score:2, Informative)
http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_s
And contrary to what you may think, it's qiute easy to use:
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? (Score:5, Informative)
Things I like better in Valgrind:
Things I like better in Purify:
Re:Strangeness (Score:2, Informative)
Re:Strangeness (Score:3, Informative)
(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 (Score:2, Informative)
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
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 (Score:3, Informative)
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 (Score:2, Informative)
Cool.
Re:Valgrid is not as complete as Purify (Score:3, Informative)
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:
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? (Score:1, Informative)
Re:Market for commercial programming tools for Lin (Score:2, Informative)
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... (Score:2, Informative)
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 [hp.com]. 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 [hp.com] (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 (Score:3, Informative)
- 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 (Score:3, Informative)
Re:Any reviews? (Score:2, Informative)
Details about Valgrind suppressions at:
http://developer.kde.org/~sewardj/docs/manua