Unload model plugins when the model is removed from the world

[diegoferigo]

As discussed in #39 (comment), model plugins are not unloaded when the model is removed from the world.

There are few problems that this behaviour could cause:

1. Memory leak. If the simulation is very long and models are inserted and deleted multiple times, the RAM consumption slowly increases. (e.g. Possible log playback memory leak #47)
2. If the plugin access ECM components of the model and it does not handle properly the case when they are not found (because the model has been removed), the behaviour could be undefined.

In #39 the problem was acknowledged but no specific issue was opened to track it.

[ejalaa12]

Hi,
I can confirm that this problem is still present in gazebo Garden.
It's easily reproducable with an Hydrodynamics system which prints "No linear vel" once its model has been removed from the world. Which means the system is still running, but the entity is not present anymore.

Are there any update on this issue ? If, you can tell where I should look, I can create a PR with a fix.

[takahashi-e6]

Hi.

This problem seems to occur in Fortress as well, and can be reproduced by simply deleting the plugin-enabled model with the following command:

ign service -s /world/empty/remove --reqtype ignition.msgs.Entity --reptype ignition.msgs.Boolean --timeout 5000 --req 'type: MODEL; name: "my_model"'

How can I properly delete a model?

I looked up the ign command but couldn't find the answer.

[MSZ98]

Hi,

In the gazebo_ros_pkgs -> gazebo_ros_openni_kinect.cpp -> Load() method, the GazeboRosCameraUtils plugin is loaded and stays active even after the model is removed from the simulation. When you try to add a model with a camera to the simulation again using the same namespace, gazebo_ros_openni_kinect.cpp attempts to load the GazeboRosCameraUtils plugin once more. However, an error occurs because the first GazeboRosCameraUtils plugin already created a dynamic reconfigure ROS service, and there’s an attempt to advertise the same service again.

I could use a different namespace for the new model, but this solution feels messy, and the old camera thread could still impact performance.