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

[Takuya OSHIMA]

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
>