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

[Takuya OSHIMA]

Hi,

The leak from vtkCommunicator::Broadcast(vtkDataArray *, int) which I
reported last Friday was confirmed to have been fixed, but I'm having
yet other leaks from vtkPVPluginLoader.cxx as reported today in the mail
titled "Two leaks from vtkPVPluginLoader.cxx."

In fact Apple's "leaks" reports yet more leaks. I'm only reporting
what seems to be surely coming from ParaView itself.

Takuya OSHIMA, Ph.D.
Faculty of Engineering, Niigata University
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN

From: "David Cole" <david.cole at kitware.com>
Subject: Re: [Paraview] a leak from vtkCommunicator::Broadcast(vtkDataArray *, int)
Date: Mon, 25 Aug 2008 09:43:14 -0400

> *
> 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
>