Memory leak in stage(_ros) and resulting segfault
CodeFinder2 opened this issue · 5 comments
Hi stage_ros and Stage maintainers / developers,
I've noticed that the cleanup logic in stage_ros as well as in the Stage simulator is buggy. First of all, the destructor StageNode::~StageNode() is not called when closing the Stage window or exiting the simulation via Ctrl+Q / File -> Quit. I've tested with the following command:
rosrun stage_ros stageros $(rospack find stage_ros)/world/willow-erratic.world
(By adding --prefix "xterm -e gdb -ex run --args" you can launch Stage in gdb to trace the issue more easily.)
Secondly, the memory allocated for the worldvariable (and even others) is never free'd.
I assume the problem is also related to the cleanup/exit logic of the Stage simulator itself (so I am not sure whether this issue should better be placed in the Stage repo): when closing the Stage window, exit(0) is executed which prevents calling dtors of variables with automatic storage duration, like the StageNode sn object created in main().
However, if the destructors would be invoked correctly (by modifying and re-compiling Stage, see modified version here), the simulator crashes with a segmentation fault:
debug: model era command(0.00 0.00 0.00) ($PATH_SHORTENED/libstage/model_position.cc Update)
debug: READING POSITION: [ -11.2770 23.2660 3.1416 ]
($PATH_SHORTENED/libstage/model_position.cc Update)
Stage: User closed the simulation window.
[Thread 0x7fffe77fe700 (LWP 8275) exited]
[Thread 0x7fffed2be700 (LWP 8261) exited]
[Thread 0x7fffecabd700 (LWP 8262) exited]
[Thread 0x7fffdf5fe700 (LWP 8296) exited]
debug: destroying world $PATH_SHORTENED/catkin_ws/src/stage_ros/world/willow-erratic.world >($PATH_SHORTENED/libstage/world.cc ~World)Thread 1 "stageros" received signal SIGSEGV, Segmentation fault.
0x0000000000000001 in ?? ()
(gdb) bt
#0 0x0000000000000001 in ?? ()
#1 0x00007ffff442ab04 in Stg::Model::~Model (this=0xcbf6a0,
__in_chrg=)
at $PATH_SHORTENED/libstage/model.cc:314
#2 0x00007ffff442ad4a in Stg::Model::~Model (this=0xcbf6a0,
__in_chrg=)
at $PATH_SHORTENED/libstage/model.cc:316
#3 0x00007ffff44a07ce in Stg::Ancestor::~Ancestor (this=0x6e72a0,
__in_chrg=)
at $PATH_SHORTENED/libstage/ancestor.cc:12
#4 0x00007ffff446c41d in Stg::World::~World (this=0x6e72a0,
__in_chrg=)
at $PATH_SHORTENED/libstage/world.cc:166
#5 0x00007ffff449d873 in Stg::WorldGui::~WorldGui (this=0x6e72a0,
__in_chrg=)
at $PATH_SHORTENED/libstage/worldgui.cc:244
#6 0x00007ffff449d930 in Stg::WorldGui::~WorldGui (this=0x6e72a0,
__in_chrg=)
at $PATH_SHORTENED/libstage/worldgui.cc:252
#7 0x0000000000456af9 in StageNode::~StageNode (this=0x7fffffffd2a8)
at $PATH_SHORTENED//catkin_ws/src/stage_ros/src/stageros.cpp:404
#8 0x000000000045b64a in main (argc=2, argv=0x7fffffffd668)
at $PATH_SHORTENED//catkin_ws/src/stage_ros/src/stageros.cpp:786
(gdb)
Please note that there are also some minor changes required in stage_ros to reproduce this, see stage_segfault_patch.txt patch file. In a nutshell:
- replace
exit(0)withreturn 0to call ctors - call
ros::shutdown()afterStg::World::Run()to ensure thread termination
I highly recommend these changes. I can provide a pull-request (w/o the "delete world" line), if desired.
@rtv Do you have an idea of how to fix this? As already mentioned, the problem seems to be located somewhere deep down in the object hierarchy of the libstage library code (see stack trace above).
Just want to add a minor additional insight: when stage(_ros) is started with an empty world (w/o any modelbeing created), the segfault disappears. This emphasizes the fact that there's some problem in the destruction of Stage's object hierarchy.
Also found stage_ros memory leak problem. When I opened several stage_ros simulator for training in parallel, the used memory continuously increase.
Hope this problem could be fixed.
We also found this problem which limited the usage of stage in multi agent simulation!
Our solution just add memory to "fix" it!
Hope someone can fix it~