Slow memory leak in GMapping::GridSlamProcessor::processScan and GMapping::Array2D

[joelziemann]

I am running slam_gampping to map an area and have noticed a small but increasing memory leak in openslam_gmapping
Valgrind output with sample of memory leak after running 5-10 minutes:
==402070==
==402070== 3,720 (744 direct, 2,976 indirect) bytes in 31 blocks are definitely lost in loss record 1,086 of 1,119
==402070== at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==402070== by 0x102E4F7C: GMapping::Array2D<GMapping::autoptr<GMapping::Array2D<GMapping::PointAccumulator, false> >, false>::Array2D(int, int) (in /opt/robotics/incubed-ros-pkg/lib/libslam_gmapping_nodelet.so)
==402070== by 0x10349192: GMapping::HierarchicalArray2DGMapping::PointAccumulator::HierarchicalArray2D(GMapping::HierarchicalArray2DGMapping::PointAccumulator const&) (in /opt/ros/noetic/lib/libgridfastslam.so)
==402070== by 0x1034AA7B: void std::vector<GMapping::GridSlamProcessor::Particle, std::allocatorGMapping::GridSlamProcessor::Particle >::_M_realloc_insertGMapping::GridSlamProcessor::Particle(__gnu_cxx::normal_iterator<GMapping::GridSlamProcessor::Particle*, std::vector<GMapping::GridSlamProcessor::Particle, std::allocatorGMapping::GridSlamProcessor::Particle > >, GMapping::GridSlamProcessor::Particle&&) (in /opt/ros/noetic/lib/libgridfastslam.so)
==402070== by 0x10348023: GMapping::GridSlamProcessor::init(unsigned int, double, double, double, double, double, GMapping::orientedpoint<double, double>) (in /opt/ros/noetic/lib/libgridfastslam.so)
==402070== by 0x102CA945: SlamGMapping::initMapper(sensor_msgs::LaserScan<std::allocator > const&) (in /opt/robotics/incubed-ros-pkg/lib/libslam_gmapping_nodelet.so)
==402070== by 0x102CF888: SlamGMapping::laserCallback(boost::shared_ptr<sensor_msgs::LaserScan<std::allocator > const> const&) (in /opt/robotics/incubed-ros-pkg/lib/libslam_gmapping_nodelet.so)
==402070==
==402070== LEAK SUMMARY:
==402070== definitely lost: 2,376 bytes in 94 blocks
==402070== indirectly lost: 11,696 bytes in 277 blocks
==402070== possibly lost: 4,496 bytes in 15 blocks
==402070== still reachable: 12,037,790 bytes in 4,503 blocks
==402070== of which reachable via heuristic:
==402070== stdstring : 71 bytes in 1 blocks
==402070== newarray : 776 bytes in 1 blocks
==402070== suppressed: 0 bytes in 0 blocks

Valgrind summary output after 2+ hours:

==551222==
==551222== LEAK SUMMARY:
==551222== definitely lost: 141,136 bytes in 3,187 blocks
==551222== indirectly lost: 4,014,392 bytes in 6,925 blocks
==551222== possibly lost: 4,560 bytes in 15 blocks
==551222== still reachable: 11,984,536 bytes in 4,005 blocks
==551222== of which reachable via heuristic:
==551222== newarray : 776 bytes in 1 blocks
==551222== suppressed: 0 bytes in 0 blocks

I have tracked down the memory leaks as coming from GMapping::Array2d and another in the lack of delete of GMapping::TNode::reading