Gazebo GUI segfault on exit - Plugin::Update called after plugin removed #1212
Comments
Thanks, I rebased a copy of my Metal ign-gazebo repo on #1208 and cherry-picked gazebosim/gz-gui#306 into ign-gui to get the event changes. This seems to have addressed the issue in I've added the Metal changes for ign-gui to main (because they break ABI), but see that there are quite a few changes in ign-gui6 yet to be forward ported. I'm not sure whether some of these additions will solve the remaining issues? Can you please advise which branches of ign-gui and ign-rendering I should target for the Metal changes? I might hold off investigating this issue until the pending changes to those branches have been merged and I've rebased all my changes on them. |
If you're breaking ABI on installed headers, then you'll need to target Ignition Garden. We're currently in a transition phase for what will become Garden. Once this ticket is completed you should have a sturdy base to build on top of: gazebo-tooling/release-tools#545. Until then... Maybe the safest approach is developing against Fortress and rebasing once Garden's rendering dependencies have been sorted out. |
FYI, |
|
Thanks @chapulina. By way of update on running ign-gazebo on macOS - my experimental branches seem to be very stable since rebasing on main, with no segfaults while running and only the ECM cleanup issue on exit. I think the issue has something to do with the the cleanup of the vector containing views when the ECM dtor is called - some of the pointers seem to already be invalidated which seems odd. It'll take more detailed investigation to pin the cause down but in the meanwhile it's not a show stopper for everyday use so it may be better to get the basic Metal support submitted first. I will put PRs together for all the changes I'm using in ign-gui and ign-gazebo once ign-rendering6 is merged into main (as the downstream libraries need code from both branches). They should provide a working macOS environment with a few smaller issues to mop up as follow ups. |
Not sure if it's related, but some race conditions on the views have been fixed here: #1001 |
There's another issue that I think points out the crash you're referring to, @srmainwaring: #1158 Have you by chance had any more time to look into this? If you have any more insights, feel free to comment on #1158, and we can continue the discussion there. |
@adlarkin, sorry no - it's currently in my list of 'inconvenient but not blocking' things to do with Ignition running on macOS. I plan to come back it once I've got the macOS GUI and Gazebo PR's knocked into shape and accepted. Update There is a workaround that prevents the segfault, on macOS at least, which I've posted as a comment in #1317. I'm happy to use this until an alternative is found, so will close this in lieu of #1158. |
Environment
Description
Expected behaviour
The GUI should shut down cleanly on exit (either Ctrl-C from terminal, exit button, or Quit in the GUI menu)
Actual behavior:
Steps to reproduce
The nature of the error message / segfault seems to depend on what plugins are loaded and may differ when stepping through the debugger compared to running in a terminal. Including the
EntityTreeplugin will always result in a terminal segfault on exit, although the issue can observed in a debugger with just a minimal set of GUI plugins (MinimalScene, GzSceneManager, InteractiveViewControl and CameraTracking).From what I can tell it appears that the update thread continues to call the
Plugin::Updatemethod after the plugin has been removed in the application destructorignition::gui::~Application().Could there be a problem here:
https://github.com/ignitionrobotics/ign-gazebo/blob/97f2e9c8499fdeb89d45220a89b7d570c9ce6690/src/gui/GuiRunner.cc#L265-L275
If the plugin is unloaded after the
pluginslist has been populated, but beforeplugin->Update()has been called, then the pointer would be invalid.There is also some odd behaviour in the main thread stack trace (for instance ~Application() is called 3x)?
I appreciate that I am observing this on development branch on an unsupported platform, so wouldn't usually bother the team, but I don't think the shutdown sequence is particular to macOS and I'd like to try and resolve the issue before submitting a PR for macOS Metal support based on this branch.
Output
Terminal output
Debugging message and stack trace
Main thread:
Update thread:
The
EXC_BAD_ACCESSis seen inGzSceneManager::Updateafter the plugin has been removed in the main thread.The text was updated successfully, but these errors were encountered: