[Paraview] a leak from vtkCommunicator::Broadcast(vtkDataArray *, int)

[David Cole]

But it's fixed now, right? Or is this another leak that you are reporting
now...?

On Sun, Aug 24, 2008 at 9:51 PM, Takuya OSHIMA
<oshima at eng.niigata-u.ac.jp>wrote:

> Thanks, it did fix the problem. Indeed, zero-byte allocation does not
> necessarily return a null pointer. I got a leak also on Linux from
> this test program
>
> #include <iostream>
> int main()
> { std::cout << static_cast<void *>(new char[0]) << std::endl; return 0; }
>
> as attached below (0x58fc030 is the returned address). I omit the full
> log but similarly, the "leaks" tool on OS X somehow reported a 16-byte
> leak from the zero-byte allocation.
>
> > valgrind --leak-check=full ./test
> ==18020== Memcheck, a memory error detector.
> ==18020== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.
> ==18020== Using LibVEX rev 1804, a library for dynamic binary translation.
> ==18020== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.
> ==18020== Using valgrind-3.3.0, a dynamic binary instrumentation framework.
> ==18020== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.
> ==18020== For more details, rerun with: -v
> ==18020==
> 0x58fc030
> ==18020==
> ==18020== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1)
> ==18020== malloc/free: in use at exit: 0 bytes in 1 blocks.
> ==18020== malloc/free: 1 allocs, 0 frees, 0 bytes allocated.
> ==18020== For counts of detected errors, rerun with: -v
> ==18020== searching for pointers to 1 not-freed blocks.
> ==18020== checked 164,336 bytes.
> ==18020==
> ==18020== 0 bytes in 1 blocks are definitely lost in loss record 1 of 1
> ==18020==    at 0x4C2488C: operator new[](unsigned long) (in
> /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
> ==18020==    by 0x40090B: main (in /home/ohshima/tmp/test)
> ==18020==
> ==18020== LEAK SUMMARY:
> ==18020==    definitely lost: 0 bytes in 1 blocks.
> ==18020==      possibly lost: 0 bytes in 0 blocks.
> ==18020==    still reachable: 0 bytes in 0 blocks.
> ==18020==         suppressed: 0 bytes in 0 blocks.
>
> Regards,
> Takuya
>
> Takuya OSHIMA, Ph.D.
> Faculty of Engineering, Niigata University
> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
>
>
> From: "Moreland, Kenneth" <kmorel at sandia.gov>
> Subject: RE: [Paraview] a leak from vtkCommunicator::Broadcast(vtkDataArray
> *, int)
> Date: Fri, 22 Aug 2008 12:27:42 -0600
>
> > I'm confused, too.  Perhaps new is doing something funny where when you
> allocate an array of size 0, it actual creates a buffer rather than just
> returning NULL.
> >
> > I just checked in a change that does not call new if nameLength is 0.
>  Let me know if there are still problems.
> >
> > -Ken
> >
> > ________________________________
> > From: David Cole [mailto:david.cole at kitware.com]
> > Sent: Friday, August 22, 2008 9:47 AM
> > To: Moreland, Kenneth
> > Subject: Fwd: [Paraview] a leak from
> vtkCommunicator::Broadcast(vtkDataArray *, int)
> >
> > cvs annotate says you wrote most of this method... Would you mind fixing
> it "the right way"...?
> >
> > It looks to me like if it goes into the LocalProcessId != srcProcessId
> chunks that nameLength is always 0 anyhow and we should avoid allocating a 0
> byte buffer..... (But, in which case, name is always going to be NULL for
> this case, so there shouldn't even be a SetName call when this condition is
> true....?) I'm confused.
> >
> >
> > Thanks,
> > David
> >
> > ---------- Forwarded message ----------
> > From: Takuya OSHIMA <oshima at eng.niigata-u.ac.jp<mailto:
> oshima at eng.niigata-u.ac.jp>>
> > Date: Fri, Aug 22, 2008 at 4:46 AM
> > Subject: [Paraview] a leak from vtkCommunicator::Broadcast(vtkDataArray
> *, int)
> > To: paraview at paraview.org<mailto:paraview at paraview.org>
> >
> >
> > Hi,
> >
> > I got a leak from vtkCommunicator::Broadcast(vtkDataArray *, int)
> > detected by the "leaks" tool on OS X. It looks like it's because the
> > delete operator at line 1004 of vtkCommunicator.cxx is enclosed by "if
> > (nameLength > 0)," while the new operator at line 984 is not (the leak
> > disappears if I set a name for the vtkDataArray).
> >
> > Regards,
> > Takuya
> >
> > Takuya OSHIMA, Ph.D.
> > Faculty of Engineering, Niigata University
> > 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN
> > _______________________________________________
> > ParaView mailing list
> > ParaView at paraview.org<mailto:ParaView at paraview.org>
> > http://www.paraview.org/mailman/listinfo/paraview
> >
> _______________________________________________
> ParaView mailing list
> ParaView at paraview.org
> http://www.paraview.org/mailman/listinfo/paraview
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.paraview.org/pipermail/paraview/attachments/20080825/5110d5c2/attachment.htm>