Question

I have a simple world plugin that creates several objects, waits a few seconds, deletes the old objects, and repeats this process several times.

For reasons I cannot identify, over the course of these iterations, the speed of the simulation slows down (the real time factor gets worse). Using the unix time utility to test, I've found the simulation starts off doing ~0.8 iterations per second, but after ~15 minutes of the simulation running, it gets down to 0.15 iterations per second.

As far as I can tell, nothing persists or accumulates between iterations, so I don't think it's the simulator getting cluttered with more and more objects.
According to htop, I can't see the resource usage of Gazebo increasing, so I don't think it's a memory leak, but I could be wrong.
The only thing I could think of is that one of the models created each iteration has a plugin, and the plugin may be slowing things down? However, as far as I can tell, there's only one of these plugins printing anything at any one time, as expected, so I assume they're getting suitably destructed between iterations.

Does anyone have any guesses as to the cause of this? My hacky solution is to just restart gazebo after 30 iterations, but this is hardly the best solution. You can see the relevant source code here. Thank you for your help.

Asked by david_d on 2019-01-06 15:35:26 UTC

Answer 1

I think the preferred way of deleting a model is by sending an entity_delete request. I believe this avoids various race conditions and makes sure every subcomponent of Gazebo is notified of the deletion. Here's another explanation.

And here's a snippet of code as used in gz.

msgs::Request *msg = msgs::CreateRequest("entity_delete", modelName);
transport::PublisherPtr pub = node->Advertise<msgs::Request>("~/request");
pub->WaitForConnection();
pub->Publish(*msg, true);
delete msg;

Asked by azeey on 2019-01-08 10:45:13 UTC

Comments

Ah, it's a good suggestion, I wasn't aware that method existed. Unfortunately, I can't test if that fixes the slowdown, because now it crashes on iteration 3, every single time. I have no idea why, no error messages are listed, except for a single time, where this error appeared: (__pthread_mutex_lock_full: Assertion `INTERNAL_SYSCALL_ERRNO (e, __err) != ESRCH || !robust' failed.)

Very strange...

Asked by david_d on 2019-01-09 19:24:50 UTC

Unexplainable slowdown over time

Comments

Answers

Comments