flexible-collision-library / fcl

Flexible Collision Library
https://flexible-collision-library.github.io/
Other
1.38k stars 417 forks source link

Segmentation fault in fcl::HierarchyTree<fcl::AABB>::bottomup during collision checking #455

Open arjunprasath opened 4 years ago

arjunprasath commented 4 years ago

I am using source installation of FCL (fcl-0.5 branch) with MoveIt library. Calling MoveIt's collision checking function do not result in any issue for the most part. But occasionally I encounter a seg fault in FCL. Please check the gdb backtrace for the same below:

Thread 18 "generate_path_s" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fff9ffff700 (LWP 9199)] fcl::HierarchyTree::bottomup (this=0x7fff98008560, lbeg=..., lend=) at fcl/include/fcl/broadphase/hierarchy_tree.hxx:298 298 NodeType n[2] = {min_it1, *min_it2};

0 fcl::HierarchyTree::bottomup (this=0x7fff98008560, lbeg=...,

lend=)
at /home/CodeBase/fcl/include/fcl/broadphase/hierarchy_tree.hxx:298

1 0x00007fffeca9be0d in fcl::HierarchyTree::topdown_0 (

this=this@entry=0x7fff98008560, lbeg=..., lbeg@entry=, lend=..., 
lend@entry=)
at /home/CodeBase/fcl/include/fcl/broadphase/hierarchy_tree.hxx:383

2 0x00007fffeca9bdc8 in fcl::HierarchyTree::topdown_0 (

this=this@entry=0x7fff98008560, lbeg=lbeg@entry=, lend=lend@entry=)
at /home/CodeBase/fcl/include/fcl/broadphase/hierarchy_tree.hxx:376

3 0x00007fffeca9bdb6 in fcl::HierarchyTree::topdown_0 (

this=this@entry=0x7fff98008560, lbeg=lbeg@entry=, lend=lend@entry=)
at /home/CodeBase/fcl/include/fcl/broadphase/hierarchy_tree.hxx:375

4 0x00007fffeca9bdb6 in fcl::HierarchyTree::topdown_0 (

this=this@entry=0x7fff98008560, lbeg=lbeg@entry=, lend=lend@entry=)
at /home/CodeBase/fcl/include/fcl/broadphase/hierarchy_tree.hxx:375

5 0x00007fffeca9bdb6 in fcl::HierarchyTree::topdown_0 (

this=this@entry=0x7fff98008560, lbeg=, lend=)

---Type to continue, or q to quit--- at /home/CodeBase/fcl/include/fcl/broadphase/hierarchy_tree.hxx:375

6 0x00007fffeca9c378 in fcl::HierarchyTree::topdown (lend=...,

lbeg=..., this=0x7fff98008560)
at /home/CodeBase/fcl/include/fcl/broadphase/hierarchy_tree.hxx:324

7 fcl::HierarchyTree::init_0 (this=0x7fff98008560,

leaves=std::vector of length 26, capacity 26 = {...})
at /home/CodeBase/fcl/include/fcl/broadphase/hierarchy_tree.hxx:465

8 0x00007fffeca97b06 in fcl::HierarchyTree::init (

level=<optimized out>, 
leaves=std::vector of length 26, capacity 26 = {...}, this=0x7fff98008560)
at /home/CodeBase/fcl/include/fcl/broadphase/hierarchy_tree.hxx:65

9 fcl::DynamicAABBTreeCollisionManager::registerObjects (

this=0x7fff98008500, 
other_objs=std::vector of length 26, capacity 26 = {...})
at /home/CodeBase/fcl/src/broadphase/broadphase_dynamic_AABB_tree.cpp:659

10 0x00007ffff003ec56 in collision_detection::FCLObject::registerTo(fcl::BroadPhaseCollisionManager*) ()

from /home/CodeBase/ws_moveit/devel/.private/moveit_core/lib/libmov---Type to continue, or q to quit--- eit_collision_detection_fcl.so.1.0.1

11 0x00007ffff0051c61 in collision_detection::CollisionEnvFCL::checkSelfCollisionHelper(collision_detection::CollisionRequest const&, collision_detection::CollisionResult&, moveit::core::RobotState const&, collision_detection::AllowedCollisionMatrix const*) const ()

from /home/CodeBase/ws_moveit/devel/.private/moveit_core/lib/libmoveit_collision_detection_fcl.so.1.0.1

12 0x0000000000556f9a in planning_scene::PlanningScene::checkCollision (

this=0xe4d530, req=..., res=..., robot_state=...)
at /home/CodeBase/ws_moveit/src/moveit/moveit_core/planning_scene/include/moveit/planning_scene/planning_scene.h:393

Any help is appreciated!

SeanCurtis-TRI commented 4 years ago

Presumably, you have no idea what collision objects were participating and what their relative configurations were, right? That's all buried inside moveit?

SeanCurtis-TRI commented 4 years ago

Oops...it's not actually part of a query. It's just trying to add a collision object to the dynamic aabb....something to ponder.

arjunprasath commented 4 years ago

I am guessing the collision objects include different links of the arm, end-effector, a cuboid representing floor and octomap. I have encountered the issue even in the absence of octomap.

SeanCurtis-TRI commented 4 years ago

Given the nature of the error message, next time you're in gdb, could you provide some insight into which iterator is the problem? NodeType* n[2] = {*min_it1, *min_it2}; Is it min_it1, 2 or both?

arjunprasath commented 4 years ago

Looks like both iterators are not pointing to any memory: (gdb) p min_it1 $6 = Cannot access memory at address 0x0 (gdb) p min_it2 $7 = Cannot access memory at address 0x0