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."

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:Valgrid is not as complete as Purify

[mce]

The bad thing about Purify is that there ain't no Linux version.

I have used Purify ever since it was first put onto the market by Pure Software about a decade ago. But nowadays, Linux is becoming our real development platform, so if Rational ain't careful: exit Purify. Yes, it's sad, but I've told them often enough that Linux support is what they should bring me, not yet another rewrite of their licensing scheme.

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.

I think you're confused

[adam_megacz]

There is no "GNU version of Java".

GCJ supports everything in Java 1.2 except for AWT (most people aren't using Java for GUIs anyways), almost all of the 1.3 stuff, and a large portion of the 1.4 stuff.

Most Java software out there today (Tomcat, etc) is designed for Java 1.2. Not much changed in 1.3/1.4.

In a pinch, you can actually take the .jar's from Sun's Java distro, run them through GCJ, and get native code binaries. You can't redistribute these, but it's handy if you're writing server code rather than shrinkwrapped software.

Could Valgrind be an alternative to Bochs?

[splorf]

It looks like it has its own instruction level simulator that does binary translation and runs a lot faster than Bochs. It may not try to simulate privileged instructions, but maybe that could be added, so you could run operating systems under Valgrind.

Could some kind of merge be possible, adapting Bochs to use Valgrind's simulator without the malloc-checking stuff? Also, I wonder if Valgrind could be adapted to simulate other CPU's besides the x86.

Re:PurifyPlus+MSDEV.EXE+icl.exe has yet to be beat

[Anonymous Coward]

Fix and continue is a bit of a joke. I'd like to think that I don't write software so poor that it actually saves time to be able to fix a bug and move immediately onto the next one without stopping, thinking, and rebuilding. ;)

At any rate, I've yet to see an IRIX debugger 'way better than VS7'. How is it way better?

Speedshop sucks ass compared to a Quantify/VTune combo.

SGI don't have a compiler even close to the Intel compiler (I'm talking C++ compliance, here.), despite the fact that they both use the EDG front end.

As for purify... how would you improve it? It's one of the few pieces of software around that is just.. done? It's complete. I use it, and I've never thought 'argh, I wish it could do..' Seriously, what is purify lacking?

P.S. the dev team (who I email from time to time) have stayed completely intact (save for the odd "background" coming and going)) from the time they were Pure, through Pure/Atria, and now Rational. Purify is the result of corporate takeover done right. ;)

Can you imagine what would've happened if MS bought purify? ;)

Re:Valgrid is not as complete as Purify

[Pauly]

Especially since purify doesn't run on linux...

Excellent point. It's also another reason why I've found Parasoft's Insure++ [parasoft.com] to be superior to Purify.

I'm sincerely looking forward to checking out Valgrind. Can someone post a feature comparison of these three?

Market for commercial programming tools for Linux

[jreiser]

I developed a product for Linux/x86 with functionality similar to Purify and valgrind, and offered it for sale three years ago (June 1999) at $99 per user. Market response was underwhelming: in eleven weeks only seven licenses were purchased, and three of those were by competitors or academics who ran the tool only to find out how it worked, and never used it beyond that.

Today BitWagon offers a profiling product tsprof [bitwagon.com] which requires no recompile and no relink, and handles main programs, shared libraries, dynamic modules, pthreads, and SMP; does direct time and event measurement based on hardware counters (no sampling) and provides highly effective interactive graphic output in addition to tabular text. So far, response again lags. Maybe Rational is onto something.

Re:What's the fun in that?

[Anonymous Coward]

So, basically, you are saying that you work in the most inefficent way possible because it makes you more manly. I tire of people who will try new tools and techniques because it isn't the way our forefathers did it. Bottom line: I can find and fix defects faster with a debuggers and such than with prinln/>>/printf etc. Hence, the reason we call it a "Poor Man's Debugger." As an engineer, you should always be looking to improve the efficency with which you work. End of discussion.

Whether or not you like Purify and its ilk are inconsequential, but your refusal to open your mind to new methods and techniques are what repulses people. Attitudes like yours create COBOL and FORTRAN system maintainers -- not true software engineers.

Re:Any reviews?

[Charles Kerr]

On a Pentium 450 running Limbo, I can start up Pan [rebelbase.com] 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.

Linux and glibc impediments to programming tools

[jreiser]

Win32 has a not-so-secret advantage: VirtualQuery(), a random-access, binary structure interface to /proc/pid/maps. It's painful being required to parse a sequential text file that does not quote filenames in order to ascertain the status of the address space.

And wouldn't you really rather be told when the dynamic linker has added or removed modules? The current interface to DT_DEBUG, _r_debug.r_brk, _dl_debug_state might be suitable for a controlling process, but it's painful for a same-process debugger. For instance, on x86 there might be only one byte of code at _dl_debug_state(), so you cannot easily overwrite it with an arbitrary transfer of control. And if you use an int3 and SIGTRAP handler, then you cannot run gdb at the same time.

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.com], 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.

Re:Valgrid is not as complete as Purify

[Citizen of Earth]

the ability to detect array bound violations (Purify's ABR/ABW)

Practically speaking, I think that it frequently does. It allocates memory blocks in such a way that writing beyond the end of an array (or before the start) is detected as a bad-memory access, so it will catch array-bounds problems for dynamically-allocated 1D arrays and frequently n-D arrays.

Re:Use garbage collection

[cpeterso]

The Be kernel was written in C, not C++. Be's user libraries were written in C++.

Interestingly though, Apple does use (a simplified subset of) C++ for Mac OS X device drivers. See the Apple IOKits.

Re:This shows the weak spot of C++

[Gumpu]

It's not so much a problem of C++ as a problem of the sloppyness of the programmer. Keep track of all the new and deletes in C++ is difficult. However GC, as found in Java, is not a magic bullet.

It is possible to leak memory in Java too (by making circular structures).

Even worse, because objects stay around until the last reference to it is gone, it is possible to have several copies of the same object lying around. This can lead to very hard to find errors.

For instance:

An object A might contain a reference to object B.
An object A2 might also contain a reference to object B, but to an older version. (Due to update error or so).

You think they both point to the same object B, and use A and A2 accordingly. Your program will not crash, because both references point to a valid object, but it won't function correctly either. It might fail only after a very long time, due to other errors that are induced by this error. This will make it very hard to find the error.

Have fun,
Frans.