[vtkusers] memory-related problem detected using Valgrind

[Marie-Gabrielle Vallet]

David,

I think you're right. Following is a part of the Valgrind output. It seems
the problem is in my graphic card driver, not in VTK. I should have read it
more carefully.

I'm glad to know such flaws are nightly checked. Thanks.
The next step for me is to find another way to debug my code...

Marie-Gabrielle Vallet


==4474== Conditional jump or move depends on uninitialised value(s)
==4474==    at 0x3F4201868E: (within
/usr/lib64/nvidia/libGLcore.so.1.0.9762)
==4474==    by 0x3F42016BE8: (within
/usr/lib64/nvidia/libGLcore.so.1.0.9762)
==4474==    by 0x3F42015BCA: (within
/usr/lib64/nvidia/libGLcore.so.1.0.9762)
==4474==    by 0x3F41B6B278: (within
/usr/lib64/nvidia/libGLcore.so.1.0.9762)
==4474==    by 0x3F41B12205: (within
/usr/lib64/nvidia/libGLcore.so.1.0.9762)
==4474==    by 0x3F41B10EAC: (within
/usr/lib64/nvidia/libGLcore.so.1.0.9762)
==4474==    by 0x392BD6F61E:
vtkOpenGLPolyDataMapper::RenderPiece(vtkRenderer*, vtkActor*) (in
/usr/lib64/libvtkRendering.so.5.0.3)
==4474==    by 0x392BD0FED9: vtkPolyDataMapper::Render(vtkRenderer*,
vtkActor*) (in /usr/lib64/libvtkRendering.so.5.0.3)
==4474==    by 0x392BD65010: vtkOpenGLActor::Render(vtkRenderer*,
vtkMapper*) (in /usr/lib64/libvtkRendering.so.5.0.3)
==4474==    by 0x392BCAE64E: vtkActor::RenderOpaqueGeometry(vtkViewport*)
(in /usr/lib64/libvtkRendering.so.5.0.3)
==4474==    by 0x392BD276E4: vtkRenderer::UpdateGeometry() (in
/usr/lib64/libvtkRendering.so.5.0.3)
==4474==    by 0x392BD7AC15: vtkOpenGLRenderer::DeviceRender() (in
/usr/lib64/libvtkRendering.so.5.0.3)


2008/2/4, David Cole <david.cole at kitware.com>:
>
> Valgrind is run nightly on "dash6.kitware" on the VTK dashboards.
>
> Here are last night's results:
>
> http://www.vtk.org/Testing/Sites/dash6.kitware/Linux-g++/20080204-0300-Nightly/DynamicAnalysis.html
>
> While there are a handful of tests that show some problems on this
> valgrind run, this is the result of running more than 600 test programs as
> part of the nightly dashboard on that machine. And when you dig into these,
> you will often encounter valgrind identifying issues in non-VTK code
> (XWindows implementation shared libs, Mesa shared libs, others)
>
> If you could pinpoint the uninitialized value and demonstrate that it
> comes from someplace in the VTK source tree, I'd be happy to correct it and
> commit a fix to the VTK code.
>
>
> Thanks,
> David Cole
> Kitware, Inc.
>
>
> On 2/4/08, Marie-Gabrielle Vallet <mgv.research at gmail.com> wrote:
>
> > I believed I had a memory-related problem with my vtk code. I ran it through
> > Valgrind, a memory checking program. It detects some problems :
> >   Conditional jump or move depends on uninitialised value(s)
> >   Use of uninitialised value of size 8
> >   Invalid read of size 8
> >
> > BUT, running Valgrind on the very simple following code results in the
> > same messages... that's disturbing!
> >
> > Has someone ever checked any vtk software for such flaws ?
> >
> > Marie-Gabrielle Vallet
> >
> > _______________________________________________
> > This is the private VTK discussion list.
> > Please keep messages on-topic. Check the FAQ at:
> > http://www.vtk.org/Wiki/VTK_FAQ
> > Follow this link to subscribe/unsubscribe:
> > http://www.vtk.org/mailman/listinfo/vtkusers
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vtk.org/pipermail/vtkusers/attachments/20080204/da3f17b5/attachment.htm>