Open Fabse92 opened 8 years ago
See also [MoveIt!] Certain .stl files can't be used on ROS Answers.
@Fabse92: it would be ideal if you could provide a gdb
backtrace, so we can see where it is crashing.
That could also confirm whether the high nr of faces/verts is a problem, or something else is going wrong.
-11
is a SEGFAULT
, pointing to a pointer problem. It could be that the STLs that happen to be highly detailed are also malformed in some way, and the STL loader isn't properly guarded against that.
Alternative: providing us with an example of an STL that makes the MSA crash would work as well.
How do I create the gdb backtrace you need?
Running /opt/ros/indigo/lib/moveit_setup_assistant/moveit_setup_assistant
in gdb
, triggering the crash and then asking gdb
for the backtrace (bt
).
The best backtrace would be done on a source build though. Not sure how comfortable you are with building things yourself, but see Source Installation Instructions. An alternative could be the Docker images: Using Docker Containers with MoveIt!.
@gavanderhoorn perhaps you could expand my just-proposed tutorial on testing to have a section on using gdb to get a backtrace?
Hopefully this is what you need:
*** Error in `/opt/ros/indigo/lib/moveit_setup_assistant/moveit_setup_assistant': malloc(): memory corruption: 0x0000000002d1f2b0 ***
Program received signal SIGABRT, Aborted.
0x00007ffff58fec37 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0 0x00007ffff58fec37 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
#1 0x00007ffff5902028 in __GI_abort () at abort.c:89
#2 0x00007ffff593b2a4 in __libc_message (do_abort=1,
fmt=fmt@entry=0x7ffff5a496b0 "*** Error in `%s': %s: 0x%s ***\n")
at ../sysdeps/posix/libc_fatal.c:175
#3 0x00007ffff5948e26 in malloc_printerr (ptr=0x2d1f2b0,
str=0x7ffff5a45882 "malloc(): memory corruption",
action=<optimized out>) at malloc.c:4996
#4 _int_malloc (av=0x7ffff5c86760 <main_arena>, bytes=180712)
at malloc.c:3447
#5 0x00007ffff594a6c0 in __GI___libc_malloc (bytes=180712)
at malloc.c:2891
#6 0x00007ffff5f01dad in operator new(unsigned long) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7 0x00007ffff5f01ea9 in operator new[](unsigned long) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#8 0x00007fffecd42e6b in ?? () from /usr/lib/libassimp.so.3
#9 0x00007fffecb739f6 in ?? () from /usr/lib/libassimp.so.3
#10 0x00007fffecb7e2c3 in Assimp::Importer::ReadFile(char const*, unsigned int) () from /usr/lib/libassimp.so.3
#11 0x00007fffecb80fdd in Assimp::Importer::ReadFileFromMemory(void const*, unsigned long, unsigned int, char const*) ()
from /usr/lib/libassimp.so.3
#12 0x00007fffef53b130 in shapes::createMeshFromBinary(char const*, unsigned long, Eigen::Matrix<double, 3, 1, 0, 3, 1> const&, std::string const&) () from /opt/ros/indigo/lib/libgeometric_shapes.so
#13 0x00007fffef53b3e3 in shapes::createMeshFromResource(std::string const&, Eigen::Matrix<double, 3, 1, 0, 3, 1> const&) ()
from /opt/ros/indigo/lib/libgeometric_shapes.so
#14 0x00007ffff4ffd4bc in moveit::core::RobotModel::constructShape(urdf::Geometry const*) ()
from /opt/ros/indigo/lib/libmoveit_robot_model.so
#15 0x00007ffff4fff6fc in moveit::core::RobotModel::constructLinkModel(urdf::Link const*) ()
from /opt/ros/indigo/lib/libmoveit_robot_model.so
---Type <return> to continue, or q <return> to quit---
@Fabse92: sorry for not getting back to you (or following @davetcoleman's suggestion).
Just to check some things, could you attach a zip with the first 100 bytes of a mesh that causes you problems?
You could use dd
for that: dd if=/path/to/your/problematic/mesh.stl of=mesh_part.stl count=100 bs=1
Perhaps related to this, the setup assistant crashes when using meshes in the .wrl
format - converting them to .stl
with meshlab and replacing the reference in the URDF works fine.
@gavanderhoorn Sorry, for answering so late, but here is the file I retrieved by using your command.
Just took a quick look, and the STL you linked seems to have only 11272
faces (in the header). Is this after you've downsampled the mesh, or is this not a mesh that causes the crash?
@wxmerkt: I'm not sure that is related.
Officially btw, only stl
, obj
and the native Ogre format are supported (by the various mesh-handling tools in ROS, not necessarily the MSA). Assimp supports much more, but there could be issues with the mesh handling code that prevent the rest of the infrastructure from succesfully handling other formats (assimp should abstract those details away, but it isn't perfect).
@Fabse92: is this still a problem with the latests build(s) of MoveIt? Which OS is this on, and is this a from-source or a binary installation?
@gavanderhoorn This is from the mesh that causes the crash. You are correct it has 11272 faces and 5600 vertices. I forgot the bs=1 part of the command, if the provided file doesn't work for you, I can upload a new one. Maybe I can upload even the whole mesh.
I use Indigo on Ubuntu 14.04, I installed with binary. Currently I have no system with the latest build of MoveIt to test this.
I forgot the bs=1 part of the command
well, I snuck that in after I saw that your file was larger than the 100 bytes I expected ;)
Maybe I can upload even the whole mesh.
That would be nice.
I use Indigo on Ubuntu 14.04, I installed with binary. Currently I have no system with the latest build of MoveIt to test this.
What is the output of dpkg -l | grep moveit
?
Here is the whole mesh.
Currently I use this full mesh as visual geometry and for collision the simplified one, which is working fine with MoveIt. It only crashes, if this mesh is used as collision geometry.
This is the output:
$ dpkg -l | grep moveit
ii ros-indigo-moveit-commander 0.7.6-0trusty-20161230-110410-0800 amd64 Python interfaces to MoveIt
ii ros-indigo-moveit-core 0.7.6-0trusty-20161230-084833-0800 amd64 Core libraries used by MoveIt!
ii ros-indigo-moveit-fake-controller-manager 0.7.6-0trusty-20161230-095035-0800 amd64 A fake controller manager plugin for MoveIt.
ii ros-indigo-moveit-full 0.6.1-0trusty-20161018-203607-0700 amd64 All MoveIt components and plugins
ii ros-indigo-moveit-ikfast 3.1.1-0trusty-20160629-033025-0700 amd64 Generates a IKFast kinematics plugin for MoveIt using OpenRave generated cpp files.
ii ros-indigo-moveit-kinematics 0.7.6-0trusty-20161230-095927-0800 amd64 Package for all inverse kinematics solvers in MoveIt!
ii ros-indigo-moveit-msgs 0.7.5-0trusty-20161115-132254-0800 amd64 Messages, services and actions used by MoveIt
ii ros-indigo-moveit-planners 0.7.6-0trusty-20161230-100852-0800 amd64 Metapacakge that installs all available planners for MoveIt
ii ros-indigo-moveit-planners-ompl 0.7.6-0trusty-20161230-100247-0800 amd64 MoveIt interface to OMPL
ii ros-indigo-moveit-plugins 0.7.6-0trusty-20161230-095230-0800 amd64 Metapackage for moveit plugins.
ii ros-indigo-moveit-ros 0.7.6-0trusty-20161230-113434-0800 amd64 Components of MoveIt that use ROS
ii ros-indigo-moveit-ros-benchmarks 0.7.6-0trusty-20161230-101738-0800 amd64 MoveIt tools for benchmarking
ii ros-indigo-moveit-ros-benchmarks-gui 0.7.6-0trusty-20161230-112127-0800 amd64 MoveIt GUI tools for benchmarking
ii ros-indigo-moveit-ros-control-interface 0.7.6-0trusty-20161230-090924-0800 amd64 ros_control controller manager interface for MoveIt!
ii ros-indigo-moveit-ros-manipulation 0.7.6-0trusty-20161230-103927-0800 amd64 Components of MoveIt used for manipulation
ii ros-indigo-moveit-ros-move-group 0.7.6-0trusty-20161230-100719-0800 amd64 The move_group node for MoveIt
ii ros-indigo-moveit-ros-perception 0.7.6-0trusty-20161230-090723-0800 amd64 Components of MoveIt connecting to perception
ii ros-indigo-moveit-ros-planning 0.7.6-0trusty-20161230-092613-0800 amd64 Planning components of MoveIt that use ROS
ii ros-indigo-moveit-ros-planning-interface 0.7.6-0trusty-20161230-104828-0800 amd64 Components of MoveIt that offer simpler interfaces to planning and execution
ii ros-indigo-moveit-ros-robot-interaction 0.7.6-0trusty-20161230-095337-0800 amd64 Components of MoveIt that offer interaction via interactive markers
ii ros-indigo-moveit-ros-visualization 0.7.6-0trusty-20161230-111452-0800 amd64 Components of MoveIt that offer visualization
ii ros-indigo-moveit-ros-warehouse 0.7.6-0trusty-20161230-100348-0800 amd64 Components of MoveIt connecting to MongoDB
ii ros-indigo-moveit-setup-assistant 0.7.6-0trusty-20161230-112135-0800 amd64 Generates a configuration package that makes it easy to use MoveIt!
ii ros-indigo-moveit-simple-controller-manager 0.7.6-0trusty-20161230-090559-0800 amd64 A generic, simple controller manager plugin for MoveIt.
ii ros-indigo-rqt-moveit 0.5.5-0trusty-20161102-172649-0700 amd64 An rqt-based tool that assists monitoring tasks for MoveIt! motion planner developers and users.
Just a comment: the mesh you provided appears to have been exported with units set to mm
, it's about a 1000 times too large. Do you have scale
attributes on your mesh
elements?
Assimp supports much more, but there could be issues with the mesh handling code that prevent the rest of the infrastructure from succesfully handling other formats (assimp should abstract those details away, but it isn't perfect).
If someone wants to fix that issue, I'd start by looking at this weird assimp hint code
Not exactly the same problem, but another segfault issue in MoveIt Setup Assistant over at #560.
@zultron I don't think there is any relation between the segfaults.
I can solve the problem by downsampling the STL files causing the error. Now, I tested it with the Kinetic build of MoveIt and the problem is gone.
If a URDF is loaded into the Setup Assistent that uses complex meshes (about 50 000 faces or more) the following error message is given:
After simplifying the meshes, the error disappeared.