dSpaceCollide2 Virtual Method Crash

[Mitchell Hebert]

I have been using Gazebo 9 to do some monte carlo simulations and I am constantly getting this crash somewhere in the ray sensor. It seems to come down to a virtual method call in dSpaceCollide2. Any Suggestions?

#0 0x00007ffff6313428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x00007ffff631502a in __GI_abort () at abort.c:89 #2 0x00007ffff694d84d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #3 0x00007ffff694b6b6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #4 0x00007ffff694b701 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #5 0x00007ffff694c23f in __cxa_pure_virtual () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6 #6 0x00007fffedcb2fc4 in ?? () from /usr/lib/x86_64-linux-gnu/libgazebo_ode.so.9 #7 0x00007fffedcb3427 in ?? () from /usr/lib/x86_64-linux-gnu/libgazebo_ode.so.9 #8 0x00007fffedcb4447 in dSpaceCollide2 () from /usr/lib/x86_64-linux-gnu/libgazebo_ode.so.9 #9 0x00007ffff595a752 in gazebo::physics::ODEMultiRayShape::UpdateRays() () from /usr/lib/x86_64-linux-gnu/libgazebo_physics.so.9 #10 0x00007ffff5a889aa in gazebo::physics::MultiRayShape::Update() () from /usr/lib/x86_64-linux-gnu/libgazebo_physics.so.9 #11 0x00007ffff6073c61 in gazebo::sensors::RaySensor::UpdateImpl(bool) () from /usr/lib/x86_64-linux-gnu/libgazebo_sensors.so.9 #12 0x00007ffff607b869 in gazebo::sensors::Sensor::Update(bool) () from /usr/lib/x86_64-linux-gnu/libgazebo_sensors.so.9 #13 0x00007ffff6082425 in gazebo::sensors::SensorManager::SensorContainer::Update(bool) () from /usr/lib/x86_64-linux-gnu/libgazebo_sensors.so.9 #14 0x00007ffff608602a in gazebo::sensors::SensorManager::SensorContainer::RunLoop() () from /usr/lib/x86_64-linux-gnu/libgazebo_sensors.so.9 #15 0x00007ffff36955d5 in ?? () from /usr/lib/x86_64-linux-gnu/libboost_thread.so.1.58.0 #16 0x00007ffff5de46ba in start_thread (arg=0x7fff4ffff700) at pthread_create.c:333 #17 0x00007ffff63e541d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

[Steve Peters]

osrf/gazebo is currently using a fork of ODE, so this problem may not be the fault of upstream.

As an aside, I'm currently working on moving gazebo's forked code to scpeters/ode so we can hopefully get back in sync someday.

[Mitchell Hebert]

Ahhh my apologies. Does this look like something that may have been fixed in either of those places? I am still trying to track down the exact line but it looks like this rare case https://bitbucket.org/scpeters/ode/src/6f44023660dc830147a56314ea0627a23f11ad86/ode/src/collision_space.cpp?at=default&fileviewer=file-view-default#collision_space.cpp-856.

Any suggestions? Thanks!

[Steve Peters]

I haven't seen this issue reported before in the gazebo issue tracker, but I did see it once in gazebo_ros_pkgs:

• https://github.com/ros-simulation/gazebo_ros_pkgs/pull/372#issuecomment-186823551

[Steve Peters]

We've started up discussion on osrf/gazebo at https://bitbucket.org/osrf/gazebo/issues/2453/raysensor-ode-dspacecollide2-crash

[Oleh Derevenko]

Would it be possible to build libgazebo_ode.so.9 with debug symbols and without optimizations so that the call stack could be visible?

[Oleh Derevenko]

Mitchell, don't take as an offense, but a programmer should normally know that in event of any complications the first thing he or she should do is rebuilding all the binaries involved with debug symbols and without optimizations so as to be able to see what's going on.

[Oleh Derevenko]

The issue has been abandoned by the reported. Closing.