Fix VTOL example #403
Fix VTOL example #403
Conversation
This fixes a segfault that sometimes happened on exit because the iterator of the _mavlink_handler_table was invalidated because plugins were being destructed that removed their callbacks from the map.
If instantiated earlier, the action plugin can "prepare" and by the time it's used it will have received the landed state.
This is nicer than just exiting immediately.
| @@ -136,6 +137,16 @@ void MAVLinkSystem::process_mavlink_message(const mavlink_message_t &message) | |||
| it->callback(message); | |||
| _mavlink_handler_table_mutex.lock(); | |||
| } | |||
|
|
|||
| if (_iterator_invalidated) { | |||
| // Someone messed with the map while we were doing the callback. | |||
There was a problem hiding this comment.
How can that happen? Don't we have the _mavlink_handler_table_mutex lock for preventing that?
There was a problem hiding this comment.
The problem is that we have to release the lock during the callback. If we didn't release the lock during the callback, we could lock ourselves out if the code in the callback tries to register or unregister a message.
An alternative would be to use a recursive_lock, so we wouldn't lock ourselves out, however, we would still change the map and invalidate the iterator.
There was a problem hiding this comment.
The proper solution is to have events in queues instead of callbacks, I think but we're far away from that 😞.
There was a problem hiding this comment.
I see. Well, that's fine for now :-).
|
@julianoes Is there a test of some kind that we don't have that we should have had to catch this? |
We should have integration tests in CI to catch this in the future. For now I try to eliminate one segfault or deadlock after the other when I run into it. This way I've been able to fix a couple in the past weeks. |
|
Thanks @julianoes |
Fix VTOL example
Fixes #401.