[vtk-developers] valgrind suppressions

[David Cole]

On Wed, Jan 20, 2010 at 2:43 PM, Sean McBride <sean at rogue-research.com>wrote:

> On 1/20/10 1:28 PM, David Cole said:
>
> >If anybody knows the details about contributing to zlib, point me to them.
> >I'd be happy to coordinate contributing this change back to them...
> Whether
> >they'll accept it or not, I don't know, but it's worth a shot.
>
> Well, they say in their FAQ that they knowingly introduced this (by
> changing from calloc to malloc) for performance reasons.  So I doubt
> they would change back. :( It would be interesting to know how big a
> performance impact this has.  1%? 1000%?
>

Yes. And I do not change it back to calloc. I add a single memset to 0 after
a single allocation that fixed the valgrind report on the CMake dashboard. I
am going to wait until tomorrow and inspect the VTK and ITK valgrind results
before I propose fixing it to the zlib guys...

But still: changes for "performance reasons" that introduce uninitialized
memory accesses are just plain wrong. Penn & Teller would call it something
slightly more colorful if they ever commented on C++ code.... I do not care
how fast you can decompress my data if there's the possibility that
something about it will be incorrect or that it will just plain crash. And
uninitialized data always comes back to bite you in the end.

Nothing against the zlib guys, but their answer to FAQ #36 is just wrong. It
*is* a bug and they should fix it.


Also, I feel compelled to point out :) that if zlib was not triplicated
> in CMake, VTK, and ITK that your fix from 2 months ago would have solved
> this once and for all. :)  When and if you guys switch away from CVS, it
> would be good to investigate some kind of 'Shared' repository that all
> these projects use.  IMNSHO. :)
>

We know. I agree completely... we will see to what degree we can achieve
this beyond the current kwsys and metaio sharing that we have in place
already.

thx,
David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtk-developers/attachments/20100120/c034bbfa/attachment.html>