GazeboRosPathsPlugin issues error in gzclient 8+ and performs dangerous unsafe memory operations

[peci1]

Starting with commit 9be17687922d36c566f1ffff3728f5f2b5cc6764 in gazebo8 and 29fff84872a8a9ae7f82a19919dfbbe9baa603d7 in default, gzclient started to check if all plugins passed with the -g switch are actually GUIPlugins with gazebo::GUI_PLUGIN type.

And that revealed the misuse of the plugin loading mechanism in GazeboRosPathsPlugin. It is not a GuiPlugin as required by gzclient, but a SystemPlugin. All of the work the plugin does happens in the constructor, which is why it works - the plugin loading mechanism first creates the instance, and then checks if it has the correct type (and it doesn't matter this check fails, because the constructor has already done all of the work).

This approach, though working, causes the following error message in Gazebo versions after the aforementioned commits (after failed check if (plugin->GetType() != gazebo::GUI_PLUGIN)):

System is attempting to load a plugin, but detected an incorrect plugin type. Plugin filename...

It's actually a bit of surprise for me that the loading code doesn't fail earlier at this check:

gazebo::GUIPluginPtr plugin = gazebo::GUIPlugin::Create(_filename, _filename);
if (!plugin)

which I'd expect to fail because the loaded plugin isn't of the specified class (but looking in the actual loading code in Plugin.hh, I'm convinced that it's the consequence of some pointer arithmetics and memory layout coincidence).

Actually I now observe (in ca 50% of attempts to rosrun gazebo_ros gzclient) the following segfault that happens when this plugin is loading, instead of seeing the above error message:

#0  0x00007ffff5c77523 in std::string::assign(std::string const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#1  0x00007ffff72c7d3f in operator= (__str="/home/peci1/tradr-git/drivers/gazebo7-ws/devel/lib/libgazebo_ros_paths_plugin.so", this=0x445e698)
    at /usr/include/c++/4.8/bits/basic_string.h:547
#2  gazebo::PluginT<gazebo::GUIPlugin>::Create (_filename=..., _name="/home/peci1/tradr-git/drivers/gazebo7-ws/devel/lib/libgazebo_ros_paths_plugin.so")
    at /home/peci1/tradr-git/drivers/gazebo7-ws/src/gazebo/gazebo/common/Plugin.hh:198
#3  0x00007ffff7309c6b in gazebo::gui::RenderWidget::AddPlugin (this=this@entry=0x1a1a7a0, _filename="/home/peci1/tradr-git/drivers/gazebo7-ws/devel/lib/libgazebo_ros_paths_plugin.so", 
    _elem=std::shared_ptr (count 2, weak 1) 0x40416a0) at /home/peci1/tradr-git/drivers/gazebo7-ws/src/gazebo/gazebo/gui/RenderWidget.cc:310
#4  0x00007ffff730a20f in gazebo::gui::RenderWidget::AddPlugins (this=0x1a1a7a0, _pluginFilenames=std::vector of length 1, capacity 1 = {...})
    at /home/peci1/tradr-git/drivers/gazebo7-ws/src/gazebo/gazebo/gui/RenderWidget.cc:293
#5  0x00007ffff729670e in gazebo::gui::run (_argc=_argc@entry=4, _argv=_argv@entry=0x7fffffffb888) at /home/peci1/tradr-git/drivers/gazebo7-ws/src/gazebo/gazebo/gui/GuiIface.cc:368
#6  0x0000000000401ddc in main (_argc=4, _argv=0x7fffffffb888) at /home/peci1/tradr-git/drivers/gazebo7-ws/src/gazebo/gazebo/gui/main.cc:29

It dies in Plugin::Create after running the constructor of the plugin:

194:         // Register the new controller.
195:         result.reset(registerFunc.func());
196:         result->dlHandle = dlHandle;
197:
198:         result->handleName = _name;  // the segfault is here, just string assignment

Also the randomness of the crashes suggests it can be some problem with pointer arithmetics/memory layout assumptions. But I really wonder why hasn't this segfault caused problems in previous versions of Gazebo where the same problem has been for a long time.

I propose creating a second version of the paths plugin that would be of the correct type. When that's done, we can see if the segfault has also gone... There's still possibility that the segfault is caused by my system setup (G8 on U Trusty, which requires a lot of self-compiled libraries, but it's been working for me for a long time).

[kev-the-dev]

@j-rivero Duplicate of #581, which was solved. @peci1, for legacy reasons -g was actually set to accept system plugins. Should be fixed in newer versions of gazebo8