-
Notifications
You must be signed in to change notification settings - Fork 44
Fix segfault when destroying Event objects #367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Signed-off-by: Addisu Z. Taddese <[email protected]>
Codecov Report
@@ Coverage Diff @@
## gz-common5 #367 +/- ##
==============================================
- Coverage 77.88% 77.88% -0.01%
==============================================
Files 84 84
Lines 10728 10724 -4
==============================================
- Hits 8356 8352 -4
Misses 2372 2372
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
Signed-off-by: Addisu Z. Taddese <[email protected]>
I've suppressed windows C4251 warnings in 5a6d88d although some of the data members are protected and maybe accessed by derived classes (I think the suppression is meant for when the members are private https://github.com/gazebosim/gz-utils/blob/cdd48b33405fe42f400f8ca1238115c0bcd265e3/include/gz/utils/SuppressWarning.hh#L63-L65). If this is a concern, we can make them private and create accessor member functions. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The approach seems sound. I just want to make sure that we aren't counting on current behaviors downstream (at least in our implementations).
Signed-off-by: Addisu Z. Taddese <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a test in 0c03f6b.
The solution in this PR relies on an undefined behavior (deleting through a base pointer even though it's not virtual) and puts an unusual constraint on users of the EventT class (no data members). So, I explored a different solution using That seems to fix the segfault when exiting gz-sim, but upon further testing in a more narrowly scoped test, I've found that even the destruction of the weak pointer stored in The only solution I'm left with is to provide a new API in gz-plugin that allows loading plugins with |
Superceded by gazebosim/gz-plugin#102 and friends. |
🦟 Bug fix
Summary
The segfault is caused when attempting to polymorphically destroy an
EventT
object that was instantiated inside a plugin (or any shared library loaded via dlopen) and the plugin has since been unloaded. SinceEventT
is a template, it's destructor is instantated in the translation unit that is part of the plugin and when that plugin is unloaded, the destructor is removed from memory as well. Gazebo stores pointers of the base classEvent
(notEventT
) in a container. Since the destructor ofEvent
is virtual, the system will try to call the destructor ofEventT
when destroying that container, but that function is no longer available.The solution is to ensure the destructor of
EventT
is never called. In this PR, this is accomplished by makingEvent
's destructor non-virtual and moving all data members to the base class. I believe it's safe to not callEventT
s destructor as long as the destructor is trivial andEventT
has no data members, but I would appreciate any feedback if this is not the case.Note, this will not fix the issue if an application stores
EventT
objects (instead ofEvent
objects) instantiated by plugins and the plugins get unloaded.To test, run
ign gazebo shapes.sdf
and exit usingctrl-c
.Checklist
codecheck
passed (See contributing)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.