ros-industrial / noether

Tool path planning and surface segmenter
134 stars 48 forks source link

Surface Raster Planner Demo fails #88

Open emielke12 opened 4 years ago

emielke12 commented 4 years ago

I am attempting to run the surface raster planner demo and am meeting a seg fault upon running, with no other apparent information. See below:


Checking log directory for disk usage. This may take a while.
Press Ctrl-C to interrupt
Done checking log file disk usage. Usage is <1GB.

started roslaunch server http://lich:43965/

SUMMARY
========

PARAMETERS
 * /rosdistro: melodic
 * /rosversion: 1.14.4
 * /surface_raster_planner_demo/debug_on: False
 * /surface_raster_planner_demo/filename: /home/emielke/ros...
 * /surface_raster_planner_demo/intersecting_plane_height: 0.1
 * /surface_raster_planner_demo/line_spacing: 0.15
 * /surface_raster_planner_demo/min_hole_size: 0.01
 * /surface_raster_planner_demo/min_segment_size: 0.01
 * /surface_raster_planner_demo/pt_spacing: 0.05
 * /surface_raster_planner_demo/raster_angle: 0.0
 * /surface_raster_planner_demo/raster_wrt_global_axes: False
 * /surface_raster_planner_demo/tool_offset: 0.0

NODES
  /
    surface_raster_planner_demo (noether/surface_raster_planner_application)

auto-starting new master
process[master]: started with pid [22684]
ROS_MASTER_URI=http://localhost:11311

setting /run_id to 8dcae180-6d4b-11ea-9750-38dead941d03
process[rosout-1]: started with pid [22696]
started core service [/rosout]
process[surface_raster_planner_demo-2]: started with pid [22703]
================================================================================REQUIRED process [surface_raster_planner_demo-2] has died!
process has died [pid 22703, exit code -11, cmd /home/emielke/ros_ws/devel/lib/noether/surface_raster_planner_application __name:=surface_raster_planner_demo __log:=/home/emielke/.ros/log/8dcae180-6d4b-11ea-9750-38dead941d03/surface_raster_planner_demo-2.log].
log file: /home/emielke/.ros/log/8dcae180-6d4b-11ea-9750-38dead941d03/surface_raster_planner_demo-2*.log
Initiating shutdown!
================================================================================
[surface_raster_planner_demo-2] killing on exit
[rosout-1] killing on exit
[master] killing on exit
shutting down processing monitor...
... shutting down processing monitor complete
done

Wondering if this is common, or what might have gone wrong. I followed the installation guide for VTK and PCL on the readme. Any help would be appreciated!

dave992 commented 4 years ago

I run into the same issue on Ubuntu 18.04, with ROS Melodic. Inspecting the backtrace it seems that it is caused by linking against the wrong VTK version. The full backtrace:

#0  0x00007ffff2ac5e60 in vtkAlgorithm::GetExecutive() () from /usr/lib/x86_64-linux-gnu/libvtkCommonExecutionModel-6.3.so.6.3
#1  0x00007ffff2ac7e33 in vtkAlgorithm::SetInputConnection(int, vtkAlgorithmOutput*) () from /usr/lib/x86_64-linux-gnu/libvtkCommonExecutionModel-6.3.so.6.3
#2  0x00007ffff33d8ada in vtkInteractorStyle::vtkInteractorStyle() () from /usr/lib/x86_64-linux-gnu/libvtkRenderingCore-6.3.so.6.3
#3  0x00007ffff33dec99 in vtkInteractorStyleSwitchBase::vtkInteractorStyleSwitchBase() () from /usr/lib/x86_64-linux-gnu/libvtkRenderingCore-6.3.so.6.3
#4  0x00007ffff6e7c79e in vtkInteractorStyleSwitch::vtkInteractorStyleSwitch() () from /usr/lib/x86_64-linux-gnu/libvtkInteractionStyle-6.3.so.6.3
#5  0x00007ffff6e7c83b in vtkInteractorStyleSwitch::New() () from /usr/lib/x86_64-linux-gnu/libvtkInteractionStyle-6.3.so.6.3
#6  0x00007ffff7548660 in vtkObjectFactory::CreateInstance(char const*) () from /usr/lib/x86_64-linux-gnu/libvtkCommonCore-6.3.so.6.3
#7  0x00007ffff33decc2 in vtkInteractorStyleSwitchBase::New() () from /usr/lib/x86_64-linux-gnu/libvtkRenderingCore-6.3.so.6.3
#8  0x00007ffff3387d91 in vtkRenderWindowInteractor::vtkRenderWindowInteractor() () from /usr/lib/x86_64-linux-gnu/libvtkRenderingCore-6.3.so.6.3
#9  0x00007ffff51a7d30 in vtkXRenderWindowInteractor::vtkXRenderWindowInteractor() () from /usr/local/lib/libvtkRenderingOpenGL2-7.1.so.1
#10 0x00007ffff51a7e0f in vtkXRenderWindowInteractor::New() () from /usr/local/lib/libvtkRenderingOpenGL2-7.1.so.1
#11 0x00007ffff7548660 in vtkObjectFactory::CreateInstance(char const*) () from /usr/lib/x86_64-linux-gnu/libvtkCommonCore-6.3.so.6.3
#12 0x00007ffff3387f72 in vtkRenderWindowInteractor::New() () from /usr/lib/x86_64-linux-gnu/libvtkRenderingCore-6.3.so.6.3
#13 0x00007ffff5bce2f9 in vtk_viewer::VTKViewer::VTKViewer (this=0x7fffffffc740) at /home/dave992/workspaces/noether_ws/src/noether/vtk_viewer/src/vtk_viewer.cpp:40
#14 0x00007ffff673803f in tool_path_planner::RasterToolPathPlanner::RasterToolPathPlanner (this=0x7fffffffc730) at /home/dave992/workspaces/noether_ws/src/noether/tool_path_planner/src/raster_tool_path_planner.cpp:112
#15 0x0000555555563a09 in main (argc=1, argv=0x7fffffffcad8) at /home/dave992/workspaces/noether_ws/src/noether/noether/src/surface_raster_planner_application.cpp:155

What I do find interesting is that it seems to hop through the different version of the library: 6.3 > 7.1 > 6.3

I double-checked the CMakeLists.txt file for requiring the correct version and went through the building warnings to see if there was a possible issue there, but did not find a cause yet.

gavanderhoorn commented 4 years ago

A probable cause is that 6.3 is a dependency of a dependency which is linked to the binary which fails.

So something like this:

binary
  - vtk7.1
  - other_dependency
    - vtk6.3
dave992 commented 4 years ago

A probable cause is that 6.3 is a dependency of a dependency which is linked to the binary which fails.

Wouldn't that be visible in the backtrace? Passing through the backtrace (and the code itself) it seems to directly invoke the vtk function. I did come across #86 which mentions what you explain, but building pcl_conversions from source did not solve this either.

gavanderhoorn commented 4 years ago

Wouldn't that be visible in the backtrace?

No.

The callchain isn't necessarily reflected 1-to-1 in the linking order of libraries.

You'll have to build everything which depends on PCL and/or VTK from source.

Make sure to catkin clean -y your workspace after placing new pkgs-to-be-built-from-sources in it. Already present pkgs will not get re-linked otherwise.