<div dir="ltr">But it's fixed now, right? Or is this another leak that you are reporting now...?<div><br><br><div class="gmail_quote">On Sun, Aug 24, 2008 at 9:51 PM, Takuya OSHIMA <span dir="ltr"><<a href="mailto:oshima@eng.niigata-u.ac.jp">oshima@eng.niigata-u.ac.jp</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Thanks, it did fix the problem. Indeed, zero-byte allocation does not<br>
necessarily return a null pointer. I got a leak also on Linux from<br>
this test program<br>
<br>
#include <iostream><br>
int main()<br>
{ std::cout << static_cast<void *>(new char[0]) << std::endl; return 0; }<br>
<br>
as attached below (0x58fc030 is the returned address). I omit the full<br>
log but similarly, the "leaks" tool on OS X somehow reported a 16-byte<br>
leak from the zero-byte allocation.<br>
<br>
> valgrind --leak-check=full ./test<br>
==18020== Memcheck, a memory error detector.<br>
==18020== Copyright (C) 2002-2007, and GNU GPL'd, by Julian Seward et al.<br>
==18020== Using LibVEX rev 1804, a library for dynamic binary translation.<br>
==18020== Copyright (C) 2004-2007, and GNU GPL'd, by OpenWorks LLP.<br>
==18020== Using valgrind-3.3.0, a dynamic binary instrumentation framework.<br>
==18020== Copyright (C) 2000-2007, and GNU GPL'd, by Julian Seward et al.<br>
==18020== For more details, rerun with: -v<br>
==18020==<br>
0x58fc030<br>
==18020==<br>
==18020== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 1)<br>
==18020== malloc/free: in use at exit: 0 bytes in 1 blocks.<br>
==18020== malloc/free: 1 allocs, 0 frees, 0 bytes allocated.<br>
==18020== For counts of detected errors, rerun with: -v<br>
==18020== searching for pointers to 1 not-freed blocks.<br>
==18020== checked 164,336 bytes.<br>
==18020==<br>
==18020== 0 bytes in 1 blocks are definitely lost in loss record 1 of 1<br>
==18020== at 0x4C2488C: operator new[](unsigned long) (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)<br>
==18020== by 0x40090B: main (in /home/ohshima/tmp/test)<br>
==18020==<br>
==18020== LEAK SUMMARY:<br>
==18020== definitely lost: 0 bytes in 1 blocks.<br>
==18020== possibly lost: 0 bytes in 0 blocks.<br>
==18020== still reachable: 0 bytes in 0 blocks.<br>
==18020== suppressed: 0 bytes in 0 blocks.<br>
<div class="Ih2E3d"><br>
Regards,<br>
Takuya<br>
<br>
Takuya OSHIMA, Ph.D.<br>
Faculty of Engineering, Niigata University<br>
8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN<br>
<br>
<br>
</div>From: "Moreland, Kenneth" <<a href="mailto:kmorel@sandia.gov">kmorel@sandia.gov</a>><br>
Subject: RE: [Paraview] a leak from vtkCommunicator::Broadcast(vtkDataArray *, int)<br>
Date: Fri, 22 Aug 2008 12:27:42 -0600<br>
<div class="Ih2E3d"><br>
> 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.<br>
><br>
> I just checked in a change that does not call new if nameLength is 0. Let me know if there are still problems.<br>
><br>
> -Ken<br>
><br>
> ________________________________<br>
> From: David Cole [mailto:<a href="mailto:david.cole@kitware.com">david.cole@kitware.com</a>]<br>
> Sent: Friday, August 22, 2008 9:47 AM<br>
> To: Moreland, Kenneth<br>
> Subject: Fwd: [Paraview] a leak from vtkCommunicator::Broadcast(vtkDataArray *, int)<br>
><br>
> cvs annotate says you wrote most of this method... Would you mind fixing it "the right way"...?<br>
><br>
> 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.<br>
><br>
><br>
> Thanks,<br>
> David<br>
><br>
> ---------- Forwarded message ----------<br>
</div><div class="Ih2E3d">> From: Takuya OSHIMA <<a href="mailto:oshima@eng.niigata-u.ac.jp">oshima@eng.niigata-u.ac.jp</a><mailto:<a href="mailto:oshima@eng.niigata-u.ac.jp">oshima@eng.niigata-u.ac.jp</a>>><br>
> Date: Fri, Aug 22, 2008 at 4:46 AM<br>
> Subject: [Paraview] a leak from vtkCommunicator::Broadcast(vtkDataArray *, int)<br>
</div><div class="Ih2E3d">> To: <a href="mailto:paraview@paraview.org">paraview@paraview.org</a><mailto:<a href="mailto:paraview@paraview.org">paraview@paraview.org</a>><br>
><br>
><br>
> Hi,<br>
><br>
> I got a leak from vtkCommunicator::Broadcast(vtkDataArray *, int)<br>
> detected by the "leaks" tool on OS X. It looks like it's because the<br>
> delete operator at line 1004 of vtkCommunicator.cxx is enclosed by "if<br>
> (nameLength > 0)," while the new operator at line 984 is not (the leak<br>
> disappears if I set a name for the vtkDataArray).<br>
><br>
> Regards,<br>
> Takuya<br>
><br>
> Takuya OSHIMA, Ph.D.<br>
> Faculty of Engineering, Niigata University<br>
> 8050 Ikarashi-Ninocho, Nishi-ku, Niigata, 950-2181, JAPAN<br>
> _______________________________________________<br>
> ParaView mailing list<br>
</div>> <a href="mailto:ParaView@paraview.org">ParaView@paraview.org</a><mailto:<a href="mailto:ParaView@paraview.org">ParaView@paraview.org</a>><br>
<div><div></div><div class="Wj3C7c">> <a href="http://www.paraview.org/mailman/listinfo/paraview" target="_blank">http://www.paraview.org/mailman/listinfo/paraview</a><br>
><br>
_______________________________________________<br>
ParaView mailing list<br>
<a href="mailto:ParaView@paraview.org">ParaView@paraview.org</a><br>
<a href="http://www.paraview.org/mailman/listinfo/paraview" target="_blank">http://www.paraview.org/mailman/listinfo/paraview</a><br>
</div></div></blockquote></div><br></div></div>