Memory leak in tools::mesh_to_volume_internal::ExpandNarrowband::operator()

[diekev]

There seems to be a memory leak in tools::mesh_to_volume_internal::ExpandNarrowband::operator().

Notice while using the new Platonic ops with the latest development version.

Here's (a cleaned up) part of a report from GCC 5.3's leak sanitizer:

Indirect leak of 10240 byte(s) in 5 object(s) allocated from:
    #0 0x7fc9125a530a in operator new[](unsigned long)
    #1 0x7fc8f085f73d in tree::LeafNode<int, 3u>::Buffer::Buffer(int const&)
    #2 0x7fc8f085a6f4 in tree::LeafNode<int, 3u>::LeafNode(math::Coord const&, int const&, bool)
    #3 0x7fc8f08d128b in tools::mesh_to_volume_internal::ExpandNarrowband<FloatTree, tools::QuadAndTriangleDataAdapter<math::Vec3s, math::Vec3I> >::operator()(tbb::blocked_range<unsigned long> const&)
    #4 0x7fc8f08c2b48 in tbb::start_reduce<tbb::blocked_range<unsigned long>, tools::mesh_to_volume_internal::ExpandNarrowband<FloatTree, tools::QuadAndTriangleDataAdapter<math::Vec3s, math::Vec3I> >, tbb::auto_partitioner const>::run_body(tbb::blocked_range<unsigned long>&)
    #5 0x7fc8f08b05a8 in void tbb::partition_type_base<tbb::auto_partition_type>::execute<tbb::start_reduce<tbb::blocked_range<unsigned long>, tools::mesh_to_volume_internal::ExpandNarrowband<FloatTree, tools::QuadAndTriangleDataAdapter<math::Vec3s, math::Vec3I> >, tbb::auto_partitioner const>, tbb::blocked_range<unsigned long> >(tbb::start_reduce<tbb::blocked_range<unsigned long>, tools::mesh_to_volume_internal::ExpandNarrowband<FloatTree, tools::QuadAndTriangleDataAdapter<math::Vec3s, math::Vec3I> >, tbb::auto_partitioner const>&, tbb::blocked_range<unsigned long>&)
    #6 0x7fc8f08a047b in tbb::start_reduce<tbb::blocked_range<unsigned long>, tools::mesh_to_volume_internal::ExpandNarrowband<FloatTree, tools::QuadAndTriangleDataAdapter<math::Vec3s, math::Vec3I> >, tbb::auto_partitioner const>::execute()

Full report

[OpenVDB-DevTeam]

Hi Kévin,

Thank you for reporting this! I've committed a fix please verify that it solves the problem. I was not able to detect the reported leak using Valgrind 3.11, and we don't have access the the tool you mentioned, but I did identify a problem in the code.

/Mihai

[diekev]

Hi Mihai,

As far as I can tell, the issue seems to be fixed now, thanks.

Kévin.

[OpenVDB-DevTeam]

Thank you for confirming the fix! I'll update this now with an exception safe solution.