Ask Your Question
0

How to check memory leaks in ROS nodes

asked 2015-07-15 08:54:03 -0500

Hello everyone,

I am trying to run valgrind in a somewhat complex node (an OMPL planner with Octomap and Actionlib). For this, I am running the node as:

valgrind --log-file=test.txt --leak-check=yes --track-origins=yes ./devel/lib/planner/planner goal_pose:=/move_base_simple/goal collision_map:=/octomap_full

It runs so slow I cannot test anything without spending some hours (although it works fast when running without valgrind).

Anyway, if I close the node killing it (Ctrl+C), I get many errors in the valgrind report. Some of them are:

==3227== HEAP SUMMARY:
==3227==     in use at exit: 2,407,249 bytes in 85 blocks
==3227==   total heap usage: 1,713,622 allocs, 1,713,537 frees, 280,743,319 bytes allocated
==3227== 
==3227== 28 bytes in 1 blocks are possibly lost in loss record 12 of 82
==3227==    at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3227==    by 0x704D208: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==3227==    by 0x704DDCA: std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==3227==    by 0x704DE63: std::string::reserve(unsigned long) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==3227==    by 0x8733CF2: log4cxx::helpers::Transcoder::decode(std::string const&, std::string&) (in /usr/lib/liblog4cxx.so.10.0.0)
==3227==    by 0x86EB77A: log4cxx::LogManager::getLogger(std::string const&) (in /usr/lib/liblog4cxx.so.10.0.0)
==3227==    by 0x86E6185: log4cxx::Logger::getLogger(char const*) (in /usr/lib/liblog4cxx.so.10.0.0)
==3227==    by 0x81BEE79: ros::console::impl::initialize() (in /opt/ros/indigo/lib/librosconsole_log4cxx.so)
==3227==    by 0x55C40B0: ros::console::initialize() (in /opt/ros/indigo/lib/librosconsole.so)
==3227==    by 0x55C1DFC: ??? (in /opt/ros/indigo/lib/librosconsole.so)
==3227==    by 0x4010139: call_init.part.0 (dl-init.c:78)
==3227==    by 0x4010222: _dl_init (dl-init.c:36)
==3227== 
==3227== 28 bytes in 1 blocks are possibly lost in loss record 13 of 82
==3227==    at 0x4C2B0E0: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==3227==    by 0x704D208: std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==3227==    by 0x704E930: char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward_iterator_tag) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==3227==    by 0x704ED47: std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) (in /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.19)
==3227==    by 0x86DCE10: log4cxx::Level::getAll() (in /usr/lib/liblog4cxx.so.10.0.0)
==3227==    by 0x86D31E6: log4cxx::Hierarchy::Hierarchy() (in /usr/lib/liblog4cxx.so.10.0.0)
==3227==    by 0x86EB4C4: log4cxx::LogManager::getLoggerRepository() (in /usr/lib/liblog4cxx.so.10.0.0)
==3227==    by 0x86EB700: log4cxx::LogManager::getLoggerLS(std::string const&) (in /usr/lib/liblog4cxx.so.10.0.0)
==3227==    by 0x86EB785: log4cxx::LogManager::getLogger(std::string const&) (in /usr/lib/liblog4cxx.so.10 ...
(more)
edit retag flag offensive close merge delete

1 Answer

Sort by » oldest newest most voted
0

answered 2015-07-15 09:15:38 -0500

Adolfo Rodriguez T gravatar image

Can you isolate the code you're developing to a more contained (unit) test that does not require deploying your entire system?. Otherwise, can you setup a simpler system test?.

edit flag offensive delete link more

Comments

I thought about that, but that causes three issues IMO: it takes a lot of time to develop these tests and it does not guarantee that the integration of the "modules" will be free of leaks, as some errors can be done in the integration steps. 3) it is harder to maintain. But I guess I have no choice

Javier V. Gómez gravatar image Javier V. Gómez  ( 2015-07-15 09:42:56 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2015-07-15 08:54:03 -0500

Seen: 1,700 times

Last updated: Jul 15 '15