Memory management in callback for Octomap

asked 2019-11-02 06:02:30 -0600

updated 2019-11-04 04:06:05 -0600

In the project i am working on, there is a ROS node and a C++ object pair. ROS node creates the object, listens to the subscribed topics and updates the object variables accordingly. Following is a similar class to the class of the object.


class treeEvaluator
    octomap::OcTree* treeOct;

    void update_tree(octomap::OcTree* receivedTree);

and update_tree function of treeEvaluator.cpp is as follows

void treeEvaluator::update_tree(octomap::OcTree* receivedTree)
    treeOct = receivedTree;

then i have to use the "treeOct" for some further calculations.

In the ROS node side i have created a object of treeEvaluator and uses callback as follows,

treeEvaluator evaluatorObject = treeEvaluator();

void mapCallback(const octomap_msgs::Octomap::ConstPtr &msg)
    octomap::AbstractOcTree* tree = octomap_msgs::msgToMap(*msg);
    octomap::OcTree* tree_oct = dynamic_cast<octomap::OcTree*>(tree);

I found this snippet from the email thread of the octomap (tried to link but cannot find the exact thread) and modified it to my need. since i was able to get this to work, now i'm wondering whether it is legit. I was not able look into the msgToMap function to see whether it has a 'new' inside it, so this is my question,

Do i have to delete the 'tree' and 'tree_oct' pointers inside the mapCallBack manually after


line? (would it cause a memory leak if not?) In the normal case it wont be needed since those may have to be used inside the node. But i only use them to convert the msg to Map and then update the object. they are not used inside the ROS node after that. This callback gets called frequently as octomap updates frequently.


(PS : i'm trying to run this on a Raspberry Pi, so lesser memory usage, better)

___ UPDATE 1___

It turned out to be a memory leak in the end. I had to implement two such nodes and after 1/2 hr of simulating, everything started lagging. Checking the "top" in terminal showed that one ROSNode had used around 49% of memory (7.7 GB) while other had around 42% of memory (6.6GB).

edit retag flag offensive close merge delete