Re: [Plplot-devel] valgrind [purify killer]

[Alan W. I. <ir...@be...>]

That does look like a killer app for C/C++ development which I could have
used when tracking down driver segfaults. Thanks for drawing valgrind to
my/our attention.

Does the problem with x08c go away if you comment out the plotsh3d call near
the end of the file?  It would be most interesting if our problems with 3D
shading were due to bugs in memory management.

I will give valgrind a try once CVS HEAD is working again....;-)

Also, Geoffrey, despite the current flurry of PLplot activity, I especially
hope you will contribute to the discussion of the python/plgetpos choice I
face.  I don't want to implement one way, only to find out you prefer the
other choice.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Tue, 26 Feb 2002, Geoffrey Furnish wrote:

> 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...
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>