Home | Tutorials | Wiki | Issues
Ask Your Question

roslaunch: [gazebo-2] process has died [pid 7605, exit code 139

asked 2017-06-07 04:51:37 -0500

Kaonashi gravatar image

After running my model with roslaunch for round about 10 to 20 minutes I always get the following error:

Segmentation fault (core dumped)  
[gazebo-2] process has died [pid 7605, exit code 139, cmd /opt/ros/kinetic/lib/gazebo_ros/gzserver -e ode /home/philipp/navibot_ws/src/navibot_gazebo/worlds/navibot.world __name:=gazebo __log:=/home/philipp/.ros/log/09e16ec0-4a76-11e7-a9fe-7085c23141c2/gazebo-2.log].  
log file: /home/philipp/.ros/log/09e16ec0-4a76-11e7-a9fe-7085c23141c2/gazebo-2*.log

Unfortunately no log file gazebo-2*.log is created.

I looked through my URDF model and checked my code. The problem is that I have a hard time to identify where the problem is really coming from, so I am looking for help here. I looked at the related questions here in the forum, but none of the solutions there worked for me.

This is my backtrace:

Thread 25 "gzserver" received signal SIGSEGV, Segmentation fault.                   
[Switching to Thread 0x7fff67fff700 (LWP 28488)]
gazebo::physics::World::Update (this=this@entry=0x12075a0) at /build/gazebo-nhSAPd/g
740     /build/gazebo-nhSAPd/gazebo-7.0.0+dfsg/gazebo/physics/World.cc: No such file  
(gdb) backtrace  
0  gazebo::physics::World::Update (this=this@entry=0x12075a0) at /build/gazebo-nhSA  
1  0x00007ffff62d99af in gazebo::physics::World::Step (this=this@entry=0x12075a0) a  
2  0x00007ffff62d9e25 in gazebo::physics::World::RunLoop (this=0x12075a0) at /build  
3  0x00007ffff40d95d5 in ?? () from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.  
4  0x00007ffff65ee6ba in start_thread (arg=0x7fff67fff700) at pthread_create.c:333  
5  0x00007ffff6bef82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109  
 (gdb) frame 0  
0  gazebo::physics::World::Update (this=this@entry=0x12075a0) at /build/gazebo-nhSAPd/gazebo-7.0.0+dfsg/gazebo  /physics/World.cc:740  
740     in /build/gazebo-nhSAPd/gazebo-7.0.0+dfsg/gazebo/physics/World.cc  
(gdb) frame 1  
1  0x00007ffff62d99af in gazebo::physics::World::Step (this=this@entry=0x12075a0) at /build/gazebo-nhSAPd/gazebo-7.0.0+dfsg/gazebo/physics/World.cc:672  
672     in /build/gazebo-nhSAPd/gazebo-7.0.0+dfsg/gazebo/physics/World.cc  
(gdb) frame 2  
2  0x00007ffff62d9e25 in gazebo::physics::World::RunLoop (this=0x12075a0) at /build/gazebo-nhSAPd/gazebo-  7.0.0+dfsg/gazebo/physics/World.cc:481  
481     in /build/gazebo-nhSAPd/gazebo-7.0.0+dfsg/gazebo/physics/World.cc  
(gdb) frame 3  
3  0x00007ffff40d95d5 in ?? () from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0  
(gdb) frame 4   
4  0x00007ffff65ee6ba in start_thread (arg=0x7fff67fff700) at pthread_create.c:333  
333     pthread_create.c: No such file or directory.  
(gdb) frame 5   
5  0x00007ffff6bef82d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109  
109     ../sysdeps/unix/sysv/linux/x86_64/clone.S: No such file or directory.
edit retag flag offensive close merge delete


I run my simulation on a stronger machine now and I didn't get this crash since 3 hours. (Which doesn't mean that it won't occur ;) ) But I suspect an internal problem. (Maybe memory related?) Also, when I ran the simulation headless, the error occurred much later, like after 1 hour instead of 20 minutes. Update: It still crashes on my faster machine but after a longer time. I can work with this in some way, but it is annoying of course to restart the and load kind of checkpoints.

Kaonashi gravatar imageKaonashi ( 2017-06-07 04:55:43 -0500 )edit

I'm having the exact same problem (exact same backtrace and everything). This happens in all configurations that I have tried (several desktops and cluster). Because of a problem with Gazebo8 I can't upgrade (https://github.com/ros-simulation/gazebo_ros_pkgs/issues/596) and so I would really like to resolve this problem.

nordmo1 gravatar imagenordmo1 ( 2017-08-09 06:21:47 -0500 )edit

I don't know if this helps, but I managed to get a bit further without full debug build. It seems to be a null pointer reference when signalling `worldUpdateBegin`. I'll add the full trace below, the only other piece of information that could be useful is that `this->dataPtr->resetAll` was `true` for me.

nordmo1 gravatar imagenordmo1 ( 2017-08-14 07:17:35 -0500 )edit

``` (gdb) whatis iter.second->on Attempt to take address of value not located in memory. (gdb) bt (removed frame 0 and 1) #2 gazebo::event::EventT<void (gazebo::common::updateinfo="" const&)="">::Signal<gazebo::common::updateinfo>(gazebo::common::UpdateInfo const&) (_p=..., this=<optimized out="">) at /home/jorgehn/gazebo/gazebo/common/Event.hh:379 #3 gazebo::event::EventT<void (gazebo::common::updateinfo="" const&)="">::operator()<gazebo::common::updateinfo>(gazebo::common::UpdateInfo const&) (_p=.. ```

nordmo1 gravatar imagenordmo1 ( 2017-08-14 07:19:12 -0500 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2017-08-17 03:32:21 -0500

nordmo1 gravatar image

Created bug report about this problem and possible solution here: https://bitbucket.org/osrf/gazebo/iss...

edit flag offensive delete link more


I assume that gazebo has to be installed from source for your fix?

RedJohn gravatar imageRedJohn ( 2018-08-16 03:15:51 -0500 )edit
Login/Signup to Answer

Question Tools

1 follower


Asked: 2017-06-07 00:36:57 -0500

Seen: 10,181 times

Last updated: Aug 17 '17