Ask Your Question

gzserver segfaults

asked 2016-12-08 00:03:28 -0500

chrisalbertson gravatar image

updated 2016-12-08 01:30:57 -0500

gvdhoorn gravatar image

New and up to date install of Kinetic and Ubuntu 16. I log in, open terminal and issue one command

roslaunch turtlebot_gazebo turtlebot_world.launch

and then gzserver segfaults.

I'm new to ROS but been into UNIX software development profesionally going back to the 1980's. It was always my opinion that if something I wrote segfaults it is always a bug, no matter what devious trick the user did to crash my software. I and my bosses figure I should have caught the problem with some kind of data validation or assert staetment.

Does the ROS development community have the same view on this? Should I report segfaults as bugs?

Next question are Where/how to report and most importantly, this is the very first step in the on-line totorial and it fails. How to figure out why?

Here is a cut and paste from the terminal window at the point where things start going wrong. (To address the question "what is in those .log files? The log files listed below do not exist. Apparently gazebo crashed before it could write to the log file.)

process[laserscan_nodelet_manager-9]: started with pid [18771]
process[depthimage_to_laserscan-10]: started with pid [18775]
[ INFO] [1481175480.361448318]: Finished loading Gazebo ROS API Plugin.
[ INFO] [1481175480.362918368]: waitForService: Service [/gazebo/set_physics_properties] has not been advertised, waiting...
Segmentation fault (core dumped)
[gazebo-2] process has died [pid 18708, exit code 139, cmd /opt/ros/kinetic/lib/gazebo_ros/gzserver -e ode /opt/ros/kinetic/share/turtlebot_gazebo/worlds/ __name:=gazebo __log:=/home/chris/.ros/log/7977bfb0-bd08-11e6-a492-002100e558ce/gazebo-2.log].
log file: /home/chris/.ros/log/7977bfb0-bd08-11e6-a492-002100e558ce/gazebo-2*.log
[gazebo_gui-3] process has died [pid 18729, exit code 255, cmd /opt/ros/kinetic/lib/gazebo_ros/gzclient __name:=gazebo_gui __log:=/home/chris/.ros/log/7977bfb0-bd08-11e6-a492-002100e558ce/gazebo_gui-3.log].
log file: /home/chris/.ros/log/7977bfb0-bd08-11e6-a492-002100e558ce/gazebo_gui-3*.log
edit retag flag offensive close merge delete


In your previous question about this you were running things in VMWare. Is that still the case?

gvdhoorn gravatar imagegvdhoorn ( 2016-12-08 01:57:00 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2016-12-08 01:36:28 -0500

gvdhoorn gravatar image

updated 2016-12-08 01:50:13 -0500

There are some (probably) related questions over at (searching for gazebo exit code 139) and I also believe that ros-simulation/gazebo_ros_pkgs#387 is related.

Does the ROS development community have the same view on this?

As much as I appreciate humor, doing it this way might not be conducive to you getting answers quicker on this forum.

Yes, SEGFAULTs are obviously considered problematic (I don't think you and your bosses are alone in that), so they should be reported.

How to figure out why?

I would try and start gzserver directly, not from a launch file. If it still crashes, #387 is probably not related. If it doesn't, it probably is.

Next question are Where/how to report [..]

Gazebo is slightly special, in that it is a stand-alone tool, but has a tight ROS integration available. As the crash seems to point to gazebo_ros, it's probably a good idea to first check ros-simulation/gazebo_ros_pkgs/issues. If it turns out to be on the Gazebo side, then I would try the Gazebo answers site, the troubleshooting page and finally if it does turn out to be an unknown bug, the issue tracker.

See the Support guidelines on the wiki for more information.

Some related questions on

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools


Asked: 2016-12-08 00:03:28 -0500

Seen: 1,422 times

Last updated: Dec 08 '16