Open jrutgeer opened 1 year ago
Part of the problem is SdfEntityCreator
keeps it's own mutable pointer to the ECM and can technically make calls to it at any system phase, but the PostUpdate
gets a const
ECM signalling to users that the ECM should not be modified in this phase. @mjcarroll, here's a data point where keeping a pointer to the ECM could be bad.
I'm not sure why it segfaults when called from Update
. Generally, the Update
phase is reserved for the physics system, but that's not a strict requirement . The ECM should be mutable and systems are run sequentially. This might be a bug in the way we handle removed entities int he Physics system
Description:
Calling SdfEntityCreator::RequestRemoveEntity() on a model entity from
update()
orpostUpdate()
causes a segmentation fault, so it seems thatRequestRemoveEntity()
is intended to be called only frompreUpdate()
.However the
RequestRemoveEntity()
code documentation states:In my interpretation, this implies the intention that
RequestRemoveEntity()
can be called at any time, and the entities in the queue will be removed when appropriate.So:
RequestRemoveEntity()
can only be called frompreUpdate()
.More info:
Here is an example repository. It is a system that:
box_preupdate
/box_update
/box_postupdate
,RequestRemoveEntity()
on the corresponding model entity, respectively frompreUpdate
/update
/postUpdate
,There are two sdf files included:
boxes_on_ground.sdf
) andboxes_above_ground.sdf
).By renaming the boxes in the sdf it is possible to disable the corresponding remove request.
Running
gz sim boxes_on_ground.sdf
(i.e. callingRequestRemoveEntity()
on a non-moving box) results in all boxes being removed, but thepostUpdate
box still visible in the gui. I assume this is related to, and possibly fixed by https://github.com/gazebosim/gz-sim/pull/2010.However running
gz sim boxes_above_ground.sdf
(i.e. callingRequestRemoveEntity()
on a moving box) consistently results in a segmentation fault both for theupdate
andpostUpdate
boxes: