Workaround for ogre crash on shutdown

[iche033]

🦟 Bug fix

Workaround for #1007

Summary

The INTEGRATION_load_unload test crashes with ogre 1.x. The tests checks to see if the render engine can be loaded and unloaded in a thread (which is how gz sim runs the render engine). The crash happens on ubuntu 24.04 with the system debs, see #1007 for more info.

The workaround implemented in this PR is to prevent the RenderSystem_GL plugin library from being unloaded on shutdown to avoid the crash. The plugin will be still be stopped and deleted but we do not call dlclose on it. I verified that the destructors of various objects / singletons in the plugin are called.

This is not ideal and we should find a proper solution in the future.

To test

The INTEGRATION_load_unload test should now pass with ogre 1.x on Ubuntu 24.04 with the system ogre debs:

GZ_ENGINE_TO_TEST=ogre  ./build/gz-rendering9/bin/INTEGRATION_load_unload

gz-sim should no longer crash on exit:

gz sim -v 4 -r --iterations 5 -s sensors_demo.sdf --render-engine ogre

Checklist

• Signed all commits for DCO
• Added tests
• Updated documentation (as needed)
• Updated migration guide (as needed)
• Consider updating Python bindings (if the library has them)
• codecheck passed (See contributing)
• All tests passed (See test coverage)
• While waiting for a review on your PR, please help review another open pull request to support the maintainers

Note to maintainers: Remember to use Squash-Merge and edit the commit message to match the pull request summary while retaining Signed-off-by messages.

[scpeters]

potential fix for the remaining cmake warning in gazebo-tooling/release-tools#1161

[scpeters]

potential fix for the remaining cmake warning in gazebo-tooling/release-tools#1161

testing shows that gazebo-tooling/release-tools#1161 should fix the warning

[scpeters]

minor nit; I'm still trying to understand the code

[azeey]

We now have API to load plugins with RTLD_NODELETE. This would ensure that the plugin is not actually deleted even if dlclose is called. Would changing

gz-rendering/src/RenderEngineManager.cc

Line 498 in 6a2217f

auto pluginNames = this->pluginLoader.LoadLib(pathToLib);

to LoadLib(pathToLib, true) fix this issue without any of the other changes?

[scpeters]

We now have API to load plugins with RTLD_NODELETE. This would ensure that the plugin is not actually deleted even if dlclose is called. Would changing

gz-rendering/src/RenderEngineManager.cc

Line 498 in 6a2217f

auto pluginNames = this->pluginLoader.LoadLib(pathToLib);

to LoadLib(pathToLib, true) fix this issue without any of the other changes?

testing in a draft PR: #1038

[scpeters]

We now have API to load plugins with RTLD_NODELETE. This would ensure that the plugin is not actually deleted even if dlclose is called. Would changing

gz-rendering/src/RenderEngineManager.cc

Line 498 in 6a2217f

auto pluginNames = this->pluginLoader.LoadLib(pathToLib);

to LoadLib(pathToLib, true) fix this issue without any of the other changes?

testing in a draft PR: #1038

the noble workflow passes; I've marked #1038 as ready for review

[iche033]

I think the LoadLib with RTLD_NODELETE approach keeps the gz-rendering engine plugin in memory while the changes in this PR will keep only the RenderSystem_GL ogre plugin in memory. I'm leaning towards keeping the current approach of limiting the workaround to only the GL render system plugin that's causing the issue.

I simplified the code in this PR quite a bit in 2910326. Now I manually call dlopen instead of using ogre's dynlib manager to load the plugin. The difference is that I no longer need to add the hook to control how the libraries are unloaded. All objects should still be deleted.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 75.69%. Comparing base (e187f52) to head (26425b8).
Report is 51 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1033   +/-   ##
=======================================
  Coverage   75.68%   75.69%           
=======================================
  Files         177      177           
  Lines       16959    16956    -3     
=======================================
- Hits        12835    12834    -1     
+ Misses       4124     4122    -2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[scpeters]

this has fixed CI and looks fine to me; I defer to @azeey about whether to follow the suggestion from @iche033 to use this instead of #1038

[azeey]

I was going to check if windows CI was okay, but it looks like the Ogre1 tests have been failing for a while. I thought it was just Ogre2 that was failing :(. Anyway, I'm good with this approach.

[iche033]

yeah we should try setting up ogre 2.3 on windows, #745