roslaunch: [gazebo-2] process has died [pid 7605, exit code 139
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.
Asked by Kaonashi on 2017-06-07 00:36:57 UTC
Answers
Created bug report about this problem and possible solution here: https://bitbucket.org/osrf/gazebo/issues/2332/possible-race-condition-in-eventhh-causing
Asked by nordmo1 on 2017-08-17 03:32:21 UTC
Comments
I assume that gazebo has to be installed from source for your fix?
Asked by RedJohn on 2018-08-16 03:15:51 UTC
I cannot access the repository you link @nordmo1
Asked by desmond13 on 2020-11-25 15:38:49 UTC
Comments
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.
Asked by Kaonashi on 2017-06-07 04:55:43 UTC
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.
Asked by nordmo1 on 2017-08-09 06:21:47 UTC
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 thatthis->dataPtr->resetAll
wastrue
for me.Asked by nordmo1 on 2017-08-14 07:17:35 UTC
``` (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::Signalgazebo::common::UpdateInfo(gazebo::common::UpdateInfo const&) (_p=..., this=)
3 gazebo::event::EventT::operator()gazebo::common::UpdateInfo(gazebo::common::UpdateInfo const&) (_p=..
```
Asked by nordmo1 on 2017-08-14 07:19:12 UTC