seg fault when visualizing some mesh markers with materials

[bcohen]

(This is similar to this bug: #507 but it seems to still be a problem and might merit another ticket?)

I'm finding that sometimes when I try to visualize large collada meshes with materials using visualization markers (with mesh_use_embedded_materials = true), rviz seg faults (see below). The funny thing is that it happens on some meshes and not others and I'm not sure what the difference is between them. I have a feeling that it could be the relative paths to the image files in the .dae but I'm not sure.

All of the meshes that I've tested with were pulled from 3D warehouse and I opened them in Meshlab to confirm that they work OK.

The following 3 meshes of kitchens result in the same seg fault:

1. http://sketchup.google.com/3dwarehouse/details?mid=39629359b546b957955bd553fc0664e2
2. http://sketchup.google.com/3dwarehouse/details?mid=36366b77c9650b2791eca12855b1096f
3. http://sketchup.google.com/3dwarehouse/details?mid=39629359b546b957955bd553fc0664e2

I'm on Ubuntu 11.10 64-bit w/ Groovy.

Let me know if there is anyway I can help (i.e. more debug output). Thanks in advance.

[ INFO][VisualizerApp::init][106]: rviz version 1.9.30
[ INFO][VisualizerApp::init][109]: compiled against OGRE version 1.7.3 (Cthugha)
[ INFO][RenderSystem::detectGlVersion][176]: OpenGl version: 3.3 (GLSL 3.3).
[ WARN][MessageFilter::testMessage][361]: Message from [/viz_mesh] has a non-fully-qualified frame_id [map]. Resolved locally to [/map]. This is will likely not work in multi-robot systems. This message will only print once.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7a758bf in rviz::loadMaterialsForMesh(std::string const&, aiScene const*, Ogre::MeshPtr const&) ()
from /opt/ros/groovy/lib/librviz.so
(gdb) bt
#0 0x00007ffff7a758bf in rviz::loadMaterialsForMesh(std::string const&, aiScene const*, Ogre::MeshPtr const&) ()

from /opt/ros/groovy/lib/librviz.so
#1 0x00007ffff7a75f71 in rviz::meshFromAssimpScene(std::string const&, aiScene const*) ()

from /opt/ros/groovy/lib/librviz.so
#2 0x00007ffff7a768d8 in rviz::loadMeshFromResource(std::string const&) () from /opt/ros/groovy/lib/librviz.so
#3 0x00007fffca2817fc in rviz::MeshResourceMarker::onNewMessage(boost::shared_ptr<visualization_msgs::Marker_<std::allocator > const> const&, boost::shared_ptr<visualization_msgs::Marker_<std::allocator > const> const&) ()

from /opt/ros/groovy/lib/libdefault_plugin.so
#4 0x00007fffca27fcee in rviz::MarkerBase::setMessage(boost::shared_ptr<visualization_msgs::Marker_<std::allocator > const> const&) () from /opt/ros/groovy/lib/libdefault_plugin.so
#5 0x00007fffca26f3b3 in rviz::MarkerDisplay::processAdd(boost::shared_ptr<visualization_msgs::Marker_<std::allocator > const> const&) () from /opt/ros/groovy/lib/libdefault_plugin.so
#6 0x00007fffca26f9fe in rviz::MarkerDisplay::processMessage(boost::shared_ptr<visualization_msgs::Marker_<std::allocator > const> const&) () from /opt/ros/groovy/lib/libdefault_plugin.so
#7 0x00007fffca26fc23 in rviz::MarkerDisplay::update(float, float) () from /opt/ros/groovy/lib/libdefault_plugin.so
#8 0x00007ffff7a48633 in rviz::DisplayGroup::update(float, float) () from /opt/ros/groovy/lib/librviz.so
#9 0x00007ffff7aef3a9 in rviz::VisualizationManager::onUpdate() () from /opt/ros/groovy/lib/librviz.so
#10 0x00007ffff7b03154 in rviz::VisualizationManager::qt_metacall(QMetaObject::Call, int, void**) ()

from /opt/ros/groovy/lib/librviz.so

[hershwg]

It would be great if you could build rviz with debugging symbols, i.e.
catkin_make -DCMAKE_BUILD_TYPE=Debug and get the stack trace again.
That would give the line number where it crashed. loadMaterialsForMesh()
is kind of big.

On Thu, Jul 25, 2013 at 9:02 AM, Benjamin Cohen notifications@github.comwrote:

(This is similar to this bug: #507https://github.com/ros-visualization/rviz/issues/507but it seems to still be a problem and might merit another ticket?)

I'm finding that sometimes when I try to visualize large collada meshes
with materials using visualization markers (with
mesh_use_embedded_materials = true), rviz seg faults (see below). The funny
thing is that it happens on some meshes and not others and I'm not sure
what the difference is between them. I have a feeling that it could be the
relative paths to the image files in the .dae but I'm not sure.

All of the meshes that I've tested with were pulled from 3D warehouse and
I opened them in Meshlab to confirm that they work OK.

The following 3 meshes of kitchens result in the same seg fault:
1)
http://sketchup.google.com/3dwarehouse/details?mid=39629359b546b957955bd553fc0664e2
2)
http://sketchup.google.com/3dwarehouse/details?mid=36366b77c9650b2791eca12855b1096f
3)
http://sketchup.google.com/3dwarehouse/details?mid=39629359b546b957955bd553fc0664e2

I'm on Ubuntu 11.10 64-bit w/ Groovy.

Let me know if there is anyway I can help (i.e. more debug output). Thanks
in advance.

[ INFO][VisualizerApp::init][106]: rviz version 1.9.30
[ INFO][VisualizerApp::init][109]: compiled against OGRE version 1.7.3
(Cthugha)
[ INFO][RenderSystem::detectGlVersion][176]: OpenGl version: 3.3 (GLSL
3.3).
[ WARN][MessageFilter::testMessage][361]: Message from [/viz_mesh] has a
non-fully-qualified frame_id [map]. Resolved locally to [/map]. This is
will likely not work in multi-robot systems. This message will only print
once.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7a758bf in rviz::loadMaterialsForMesh(std::string const&,
aiScene const_, Ogre::MeshPtr const&) ()
from /opt/ros/groovy/lib/librviz.so
(gdb) bt
#0 0x00007ffff7a758bf in rviz::loadMaterialsForMesh(std::string const&,
aiScene const_, Ogre::MeshPtr const&) ()
from /opt/ros/groovy/lib/librviz.so
#1 https://github.com/ros-visualization/rviz/issues/10x00007ffff7a75f71 in rviz::meshFromAssimpScene(std::string const&, aiScene
const*) ()
from /opt/ros/groovy/lib/librviz.so
#2 https://github.com/ros-visualization/rviz/issues/20x00007ffff7a768d8 in rviz::loadMeshFromResource(std::string const&) ()
from /opt/ros/groovy/lib/librviz.so
#3 https://github.com/ros-visualization/rviz/issues/30x00007fffca2817fc in
rviz::MeshResourceMarker::onNewMessage(boost::shared_ptr > const> const&,
boost::shared_ptr > const> const&) ()
from /opt/ros/groovy/lib/libdefault_plugin.so
#4 https://github.com/ros-visualization/rviz/issues/40x00007fffca27fcee in rviz::MarkerBase::setMessage(boost::shared_ptr >
const> const&) () from /opt/ros/groovy/lib/libdefault_plugin.so
#5 https://github.com/ros-visualization/rviz/issues/50x00007fffca26f3b3 in rviz::MarkerDisplay::processAdd(boost::shared_ptr >
const> const&) () from /opt/ros/groovy/lib/libdefault_plugin.so
#6 https://github.com/ros-visualization/rviz/issues/60x00007fffca26f9fe in rviz::MarkerDisplay::processMessage(boost::shared_ptr

const> const&) () from /opt/ros/groovy/lib/libdefault_plugin.so
#7 https://github.com/ros-visualization/rviz/issues/70x00007fffca26fc23 in rviz::MarkerDisplay::update(float, float) () from
/opt/ros/groovy/lib/libdefault_plugin.so
#8 https://github.com/ros-visualization/rviz/issues/80x00007ffff7a48633 in rviz::DisplayGroup::update(float, float) () from
/opt/ros/groovy/lib/librviz.so
#9 https://github.com/ros-visualization/rviz/issues/90x00007ffff7aef3a9 in rviz::VisualizationManager::onUpdate() () from
/opt/ros/groovy/lib/librviz.so
#10 https://github.com/ros-visualization/rviz/issues/100x00007ffff7b03154 in
rviz::VisualizationManager::qt_metacall(QMetaObject::Call, int, void**) ()
from /opt/ros/groovy/lib/librviz.so

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/659
.

[bcohen]

Just did it....line 549

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff79e9c26 in rviz::loadMaterialsForMesh (resource_path=..., scene=0xda1ea0, mesh=...) at /home/bcohen/ros/catkin_ws/src/rviz/src/rviz/mesh_loader.cpp:549
549 mesh->getSubMesh(i)->setMaterialName(material_lookup[scene->mMeshes[i]->mMaterialIndex]->getName());

Also, I added some debug output in case it helps:

for (uint32_t i = 0; i < mesh->getNumSubMeshes(); ++i)
{
ROS_ERROR("[submesh %d] name: %s ", int(i), material_lookup[scene->mMeshes[i]->mMaterialIndex]->getName().c_str());
mesh->getSubMesh(i)->setMaterialName(material_lookup[scene->mMeshes[i]->mMaterialIndex]->getName());
}

This is what it gave me:

[ERROR][loadMaterialsForMesh][549]: [submesh 0] name: package://pviz/kitchen2/models/kitchen2.daeMaterial0
[ERROR][loadMaterialsForMesh][549]: [submesh 1] name: package://pviz/kitchen2/models/kitchen2.daeMaterial0
[ERROR][loadMaterialsForMesh][549]: [submesh 2] name: package://pviz/kitchen2/models/kitchen2.daeMaterial0
[ERROR][loadMaterialsForMesh][549]: [submesh 3] name: package://pviz/kitchen2/models/kitchen2.daeMaterial0
[ERROR][loadMaterialsForMesh][549]: [submesh 4] name: package://pviz/kitchen2/models/kitchen2.daeMaterial20
[ERROR][loadMaterialsForMesh][549]: [submesh 5] name: package://pviz/kitchen2/models/kitchen2.daeMaterial19
[ERROR][loadMaterialsForMesh][549]: [submesh 6] name: package://pviz/kitchen2/models/kitchen2.daeMaterial20
[ERROR][loadMaterialsForMesh][549]: [submesh 7] name: package://pviz/kitchen2/models/kitchen2.daeMaterial19
[ERROR][loadMaterialsForMesh][549]: [submesh 8] name: package://pviz/kitchen2/models/kitchen2.daeMaterial20
[ERROR][loadMaterialsForMesh][549]: [submesh 9] name: package://pviz/kitchen2/models/kitchen2.daeMaterial19
[ERROR][loadMaterialsForMesh][549]: [submesh 10] name: package://pviz/kitchen2/models/kitchen2.daeMaterial34
...
[ERROR][loadMaterialsForMesh][549]: [submesh 740] name: package://pviz/kitchen2/models/kitchen2.daeMaterial10
[ERROR][loadMaterialsForMesh][549]: [submesh 741] name: package://pviz/kitchen2/models/kitchen2.daeMaterial10
[ERROR][loadMaterialsForMesh][549]: [submesh 742] name: package://pviz/kitchen2/models/kitchen2.daeMaterial10
[ERROR][loadMaterialsForMesh][549]: [submesh 743] name: package://pviz/kitchen2/models/kitchen2.daeMaterial10

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff79e9d05 in rviz::loadMaterialsForMesh (resource_path=..., scene=0x180c020, mesh=...) at /home/bcohen/ros/catkin_ws/src/rviz/src/rviz/mesh_loader.cpp:549
549 ROS_ERROR("[submesh %d] name: %s ", int(i), material_lookup[scene->mMeshes[i]->mMaterialIndex]->getName().c_str());

Also notice that the seg fault occurred on my debug statement. Notice the weird concatenation of Material to the resource name.....is that normal?

[hershwg]

The concatenation of "Material10" etc to the resource name is normal, you can see it happen around line 427. Ogre wants everything in the system to have a unique name, which is quite a hassle sometimes. Strategies like this are common, take something that's unique to the thing in question (the resource) and add a type and incrementing number tag to it. Often in rviz you just see a static int variable and a label string. This one seems marginally more sophisticated.

[hershwg]

aiScene class from assimp uses unprotected pointers for its array implementation. We are reading off the end of the scene->mMeshes[] array for some reason. Investigating...

[bcohen]

Thanks for looking into it. I wonder what's unique to the approximately 10 meshes that I've been looking at that trigger this problem as opposed to the tons of collada files that everyone's been using without a problem until now.

[hershwg]

The bug I'm seeing is that assimp supports having submeshes which are
shared and pointed to by multiple nodes. The indexing that rviz is using
seems to assume that the submeshes are never shared and match one-to-one
with the references to the submeshes.

So it's pretty plausible to me that some authoring tool uses that feature,
but most don't. As far as I can see, the rviz code with this bug is over 3
years old.

On Fri, Jul 26, 2013 at 11:31 AM, Benjamin Cohen
notifications@github.comwrote:

Thanks for looking into it. I wonder what's unique to the approximately 10
meshes that I've been looking at that trigger this problem as opposed to
the tons of collada files that everyone's been using without a problem
until now.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/659#issuecomment-21639449
.

[bcohen]

Looks to me like google products are putting out these files on 3D warehouse. (Although Trimble bought Sketchup from Google last year.)

authoring_tool>Google 3D Warehouse 1.0</authoring_tool

authoring_tool>Google SketchUp 6.0.1099</authoring_tool

authoring_tool>Google SketchUp 6.0.515</authoring_tool

authoring_tool>Google SketchUp 6.4.112</authoring_tool

[hershwg]

I think the change I just committed fixes the bug. It worked on the one model from your list that I tried (which previously failed). Please re-open if it doesn't work. Thanks!

[bcohen]

Thanks! I'll try it out right now. I noticed that you committed it to hydro-devel.....should I be able to also compile this code under groovy?

[hershwg]

I'm not sure. I'm cherry-picking this change into groovy-devel now.

On Fri, Jul 26, 2013 at 2:28 PM, Benjamin Cohen notifications@github.comwrote:

Thanks! I'll try it out right now. I noticed that you committed it to
hydro-devel.....should I be able to also compile this code under groovy?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/659#issuecomment-21649292
.

[hershwg]

OK, tested and pushed the cherry-picked change into groovy-devel.

If you have any idea why some meshes are inside-out (texture-wise), I would
love to know.

On Fri, Jul 26, 2013 at 2:32 PM, Dave Hershberger hersh@willowgarage.comwrote:

I'm not sure. I'm cherry-picking this change into groovy-devel now.

On Fri, Jul 26, 2013 at 2:28 PM, Benjamin Cohen notifications@github.comwrote:

Thanks! I'll try it out right now. I noticed that you committed it to
hydro-devel.....should I be able to also compile this code under groovy?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/659#issuecomment-21649292
.

[bcohen]

Thanks! I confirmed that it's working in groovy.

I'm seeing the same behavior with the inside-out textures. I have no idea about this stuff in general, but I would guess the normals are in the wrong direction? pure guess.

Thanks again for the super quick fix.

[bcohen]

BTW - I'm working on a team and I'm trying to figure out if I should tell them to build rviz with the fix from source or wait for the next ubuntu package... approximately how often do you push updates to the ubuntu package?

[hershwg]

I do releases whenever it seems like a good idea or when someone really
needs it. Usually takes a day or so after I do the release before the ROS
build farm gets it to shadow-fixed. From there to public is really
unreliable, sometimes weeks.

If it would really help you out, I can start one today.

On Fri, Jul 26, 2013 at 3:44 PM, Benjamin Cohen notifications@github.comwrote:

BTW - I'm working on a team and I'm trying to figure out if I should tell
them to build rviz with the fix from source or wait for the next ubuntu
package... approximately how often do you push updates to the ubuntu
package?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/659#issuecomment-21652669
.

[bcohen]

That would be sweet if it wouldn't cause any problems for you.

BTW - I'm obviously biased but I think this fix allows people to view much large scenes now from 3D Warehouse and thus do some cool stuff in rviz. This is awesome!

Do you think it's possible that the normals can have an effect on the materials? or is that insane?

[hershwg]

I don't know much about the normals. It does seem like that might be
related. However my expectation is that it is related to the winding order
of the polygons, like clockwise is the "outer" surface vs counterclockwise.
My experience with normals is that they mostly affect lighting.

On Fri, Jul 26, 2013 at 3:58 PM, Benjamin Cohen notifications@github.comwrote:

That would be sweet if it wouldn't cause any problems for you.

BTW - I'm obviously biased but I think this fix allows people to view much
large scenes now from 3D Warehouse and thus do some cool stuff in rviz.
This is awesome!

Do you think it's possible that the normals can have an effect on the
materials? or is that insane?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/659#issuecomment-21653217
.

[hershwg]

ok, pushed releases for groovy and hydro rviz with the fix. Hope it is all
you've wished for. :)

On Fri, Jul 26, 2013 at 4:15 PM, Dave Hershberger hersh@willowgarage.comwrote:

I don't know much about the normals. It does seem like that might be
related. However my expectation is that it is related to the winding order
of the polygons, like clockwise is the "outer" surface vs counterclockwise.
My experience with normals is that they mostly affect lighting.

On Fri, Jul 26, 2013 at 3:58 PM, Benjamin Cohen notifications@github.comwrote:

That would be sweet if it wouldn't cause any problems for you.

BTW - I'm obviously biased but I think this fix allows people to view
much large scenes now from 3D Warehouse and thus do some cool stuff in
rviz. This is awesome!

Do you think it's possible that the normals can have an effect on the
materials? or is that insane?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/659#issuecomment-21653217
.

[bcohen]

Thanks a lot. I appreciate it. My new viz markers of full homes look awesome with the pr2 driving around inside of it.

I'm determined to figure out the inside-out textures problem. I'll let you know when I figure out some clues.