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::HierarchicalArray2D::HierarchicalArray2D(GMapping::HierarchicalArray2D const&) (in /opt/ros/noetic/lib/libgridfastslam.so) ==402070== by 0x1034AA7B: void std::vector<GMapping::GridSlamProcessor::Particle, std::allocator >::_M_realloc_insert(__gnu_cxx::__normal_iterator<GMapping::GridSlamProcessor::Particle*, std::vector<GMapping::GridSlamProcessor::Particle, std::allocator > >, 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(sensormsgs::LaserScan<std::allocator > const&) (in /opt/robotics/incubed-ros-pkg/lib/libslam_gmapping_nodelet.so) ==402070== by 0x102CF888: SlamGMapping::laserCallback(boost::shared_ptr<sensormsgs::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