Revision history [back]

I've got a similar setup (Ubuntu 12.04, updated gazebo package, previously working), but the final error I'm getting is "Illegal instruction (core dumped)".

After seeing what runs and what doesn't, it seems to be an issue with gzserver. I ran gzserver inside gdb with a roscore running, and backtrace points vaguely to the physics engine:

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7fffb57fa700 (LWP 16593)]
0x00007ffff7bc5f01 in gazebo::common::Time::Set(double) ()
   from /opt/ros/fuerte/stacks/simulator_gazebo/gazebo/gazebo/lib/libgazebo_common.so.1
(gdb) bt
#0  0x00007ffff7bc5f01 in gazebo::common::Time::Set(double) ()
   from /opt/ros/fuerte/stacks/simulator_gazebo/gazebo/gazebo/lib/libgazebo_common.so.1
#1  0x00007ffff7455d8d in gazebo::physics::World::Step() ()
   from /opt/ros/fuerte/stacks/simulator_gazebo/gazebo/gazebo/lib/libgazebo_physics.so.1
#2  0x00007ffff74560c8 in gazebo::physics::World::RunLoop() ()
   from /opt/ros/fuerte/stacks/simulator_gazebo/gazebo/gazebo/lib/libgazebo_physics.so.1
#3  0x00007ffff6a40ce9 in thread_proxy ()
   from /usr/lib/libboost_thread.so.1.46.1
#4  0x00007ffff6c54e9a in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00007ffff58ec4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6                                                                                                           
#6  0x0000000000000000 in ?? ()

But a workaround I've found is to move the current simulator_gazebo stack ouside of where ROS can see it, and to svn checkout the simulator_gazebo stack into your ROS path and rosmake the stack.

roscd simulator_gazebo
cd ..
sudo mv simulator_gazebo ~/simulator_gazebo_bak     #(or someplace else out of the way)
cd ~/ROS     #(or somewhere in your ROS path)
svn checkout https://code.ros.org/svn/ros-pkg/stacks/simulator_gazebo/trunk simulator_gazebo
cd simulator_gazebo
rosmake

After this, gazebo works for me. I'm currently thinking the reason why it didn't work was because of how the .deb packages were made (a compile flag somewhere) but I don't know for sure.

I've got a similar setup (Ubuntu 12.04, updated gazebo package, previously working), but the final error I'm getting is "Illegal instruction (core dumped)".

After seeing what runs and what doesn't, it seems to be an issue with gzserver. I ran gzserver inside gdb with a roscore running, and backtrace points vaguely to the physics engine:

Program received signal SIGILL, Illegal instruction.
[Switching to Thread 0x7fffb57fa700 (LWP 16593)]
0x00007ffff7bc5f01 in gazebo::common::Time::Set(double) ()
   from /opt/ros/fuerte/stacks/simulator_gazebo/gazebo/gazebo/lib/libgazebo_common.so.1
(gdb) bt
#0  0x00007ffff7bc5f01 in gazebo::common::Time::Set(double) ()
   from /opt/ros/fuerte/stacks/simulator_gazebo/gazebo/gazebo/lib/libgazebo_common.so.1
#1  0x00007ffff7455d8d in gazebo::physics::World::Step() ()
   from /opt/ros/fuerte/stacks/simulator_gazebo/gazebo/gazebo/lib/libgazebo_physics.so.1
#2  0x00007ffff74560c8 in gazebo::physics::World::RunLoop() ()
   from /opt/ros/fuerte/stacks/simulator_gazebo/gazebo/gazebo/lib/libgazebo_physics.so.1
#3  0x00007ffff6a40ce9 in thread_proxy ()
   from /usr/lib/libboost_thread.so.1.46.1
#4  0x00007ffff6c54e9a in start_thread ()
   from /lib/x86_64-linux-gnu/libpthread.so.0
#5  0x00007ffff58ec4bd in clone () from /lib/x86_64-linux-gnu/libc.so.6                                                                                                           
/lib/x86_64-linux-gnu/libc.so.6
#6  0x0000000000000000 in ?? ()

But a workaround I've found is to move the current simulator_gazebo stack ouside of where ROS can see it, and to svn checkout the simulator_gazebo stack into your ROS path and rosmake the stack.

roscd simulator_gazebo
cd ..
sudo mv simulator_gazebo ~/simulator_gazebo_bak     #(or someplace else out of the way)
cd ~/ROS     #(or somewhere in your ROS path)
svn checkout https://code.ros.org/svn/ros-pkg/stacks/simulator_gazebo/trunk simulator_gazebo
cd simulator_gazebo
rosmake

After this, gazebo works for me. I'm currently thinking the reason why it didn't work was because of how the .deb packages were made (a compile flag somewhere) but I don't know for sure.