[Plplot-devel] valgrind [purify killer]

[Geoffrey F. <fu...@ga...>]

Hi All,

I wanted to take a moment to call everyone's attention to an
incredibly amazing Linux utility I discovered yesterday, valgrind.

http://devel-home.kde.org/~sewardj/

This tool is simply amazing.  I discovered it yesterday, and was able
to use it to immediately find several bugs in my own code.  I've also
spent a little time using it on PLplot, and the short statement is
that it definitely has some things to say about PLplot.

I think that some of its output is spurious/erroneous.  It seems to
finger some code that I don't believe is actually wrong, and some of
these "bug" reports migrate around as I recompile PLplot with
different versons of GCC.  I don't know if this reflects a bug in
valgrind, or in GCC.  

But anyway, there are plenty of things it finds that I don't doubt to
be real.  I fixed one problem yesterday in cmap0 initialization, that
was rooted out using valgrind.

Today I ran all the C examples through valgrind.  Omitting the ones
that produced diagnostics I suspect to be spurious, the ones of
interest are x08c, x11c, and x20c.  The first two of these seem to
utilize unitialized memory thousands of times each.  The error count
on x20c is smaller, around 500 I think, but that's still pretty
serious. 

I tried to prosecute the bugs in plot3d.c (from x08c.c), but
eventually gave up.  The bugs in there are buried too deep for me to
spot easily.  Seems to have something to do with the u and v arrays in
plot3d.c not having been initialized all the way to the last
elements.  

Anyway, I just wanted to commend this tool to everyone.  If you're
working on compiled code, you've gotta try valgrind, whether its
PLplot related or not.  This tool is just amazing.

For those whoe know Rational's purify product, this is the GPL app
that's gonna crush purify, at least on the Linux platform.  Rational
doesn't currently ship purify on Linux, and at this point, I'm sure
they never will, 'cause there's no longer a need.  valgrind does what
purify does, only perhaps arguably even better.  You'll have to read
the valgrind docs to understand why I say that, but basically it takes
the notion of code instrumentation that purify applies to individual
objects, and in valgrind this notion is translated straight to the
cpu.  The "cpu" in valgrind is a sort of Intel Architecture simulator,
which does for /any/ x86 object code, the same kind of thing that
purify does on object code it gets to massage.  Stated another way,
it's a lot like Purify, only more general.  And it's GPL'd.  

Anyway, if you work with C or C++ code on Linux, you've gotta try
valgrind.  

-- 
Geoffrey Furnish         fu...@ga...