Memory leak in node creation

[vikgus1]

Using Octomap 1.9.8.

Running Valgrind on my Octomap implementation I noticed the following:

==559639== 64 bytes in 1 blocks are definitely lost in loss record 2,913 of 6,399
==559639==    at 0x483E583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)
==559639==    by 0x12C9F9: octomap::OcTreeBaseImpl<octomap::OcTreeNode, octomap::AbstractOccupancyOcTree>::createNodeChild(octomap::OcTreeNode*, unsigned int) [clone .isra.0] (in /home/viktor/ros2_ws/src/octomap_impl/build/octomap_server/octomap_server_node)
==559639==    by 0x14C26F: octomap::OccupancyOcTreeBase<octomap::OcTreeNode>::updateNodeRecurs(octomap::OcTreeNode*, bool, octomap::OcTreeKey const&, unsigned int, float const&, bool) (in /home/viktor/ros2_ws/src/octomap_impl/build/octomap_server/octomap_server_node)
==559639==    by 0x14BFCE: octomap::OccupancyOcTreeBase<octomap::OcTreeNode>::updateNodeRecurs(octomap::OcTreeNode*, bool, octomap::OcTreeKey const&, unsigned int, float const&, bool) (in /home/viktor/ros2_ws/src/octomap_impl/build/octomap_server/octomap_server_node)
==559639==    by 0x14C3D3: octomap::OccupancyOcTreeBase<octomap::OcTreeNode>::updateNode(octomap::OcTreeKey const&, float, bool) (in /home/viktor/ros2_ws/src/octomap_impl/build/octomap_server/octomap_server_node)
==559639==    by 0x12D3A2: octomap_server::OctomapServer::insertLidarPoints(tf2::Vector3 const&, pcl::PointCloud<pcl::PointXYZIRR> const&) (in /home/viktor/ros2_ws/src/octomap_impl/build/octomap_server/octomap_server_node)

It seems that elements created with new[] are not freed with delete[]. I looked at the implementation of createNodeChild but couldn't immediately understand where the new[] was happening. I thought this might not be so bad, but after running my implementation continuously for 13 hours I had a crash because Octomap had eaten all the RAM of my pretty high end system. I also know that the memory leak is here and not in my implementation since Valgrind doesn't show any leakage in my implementation.

If anyone could have a look at this or give me a hint of how to fix the issue, I would be very grateful.

[vikgus1]

Ok I just realized that this was a duplicate of the issue fixed in #288.

[ahornung]

Thanks for the report! Just to be sure - does #288 fix the issue for you?