Robotics StackExchange | Archived questions

Gazebo crashes on model deletion

I am attempting to delete (and subsequently re-spawn, with a different 3D mesh) a static model in Gazebo. When I do, Gazebo is crashing consistently.

Here is an excerpt from the gazebo log:

gzserver: /usr/include/boost/smart_ptr/shared_ptr.hpp:653: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = gazebo::physics::Inertial; typename boost::detail::sp_member_access<T>::type = gazebo::physics::Inertial*]: Assertion `px != 0' failed.

(truncated some plugin output here, which looks sane)

Aborted (core dumped)
================================================================================REQUIRED process [gazebo-2] has died!
process has died [pid 23768, exit code 134, cmd /opt/simulation/lib/gazebo_ros/gzserver -u -r -e ode /var/tmp/ros/temp.world __name:=gazebo __log:=/home/administrator/.ros/log/eb76bd24-e192-11e6-a6dd-005056b4a883/gazebo-2.log].
log file: /home/administrator/.ros/log/eb76bd24-e192-11e6-a6dd-005056b4a883/gazebo-2*.log
Initiating shutdown!
================================================================================

I'm calling the delete service from Python, as follows:

self._delete_env_cli = rospy.ServiceProxy('/gazebo/delete_model', DeleteModel)
try:
        rospy.wait_for_service('/gazebo/delete_model')
        resp = self._delete_env_cli(model_name='barrier')
except rospy.ServiceException as e:
        rospy.logerr("Service did not process request: {}".format(e))

I see this behaviour with or without rospy.wait_for_service().

Gazebo 7.5.0, ROS Indigo. I'm also running GzWeb (head of gzweb_1.3.0) which is connected to this instance - not sure if that would impact anything.

Asked by JLiviero on 2017-01-23 13:16:27 UTC

Comments

Could you get a backtrace using gdb? http://gazebosim.org/tutorials/?tut=ros_roslaunch#Exampleroslaunchcommand

Asked by chapulina on 2017-01-23 23:25:44 UTC

Wilco. Is there a method for getting debug symbols without building Gazebo from source? Just setting debug=true indicates:

Reading symbols from gzserver...(no debugging symbols found)...done.

Asked by JLiviero on 2017-01-24 11:05:36 UTC

humm I think Gazebo needs to have been compiled in debug mode..

Asked by chapulina on 2017-01-25 11:20:49 UTC

Output has been posted below - let me know if you need anything else.

Asked by JLiviero on 2017-02-23 12:51:48 UTC

Hi @JLiviero, thanks for the backtrace. It looks like physics::Link is trying to access a null physics::Inertial pointer. I was planning on trying to reproduce the issue using Gazebo without ROS when I have some time, so it's easier to investigate.

Asked by chapulina on 2017-02-23 13:06:39 UTC

Answers

Responding to @chapulina 's request here so I can attach the file. The full backtrace is attached. The model that caused this particular crash was a simple static cylinder primitive with a blink_visual plugin (but no custom plugins), though I have seen similar (not backtraced) crashes occur on a variety of models.

The attachment is just a text file, but has a .msg extension since this board only allows certain file types.

C:\fakepath\gz_backtrace.msg

Asked by JLiviero on 2017-02-13 15:19:41 UTC

Comments