Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Surface Raster Planner Demo fails #88

Open
emielke12 opened this issue Mar 23, 2020 · 4 comments
Open

Surface Raster Planner Demo fails #88

emielke12 opened this issue Mar 23, 2020 · 4 comments

Comments

@emielke12
Copy link

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
Copy link

dave992 commented Jun 6, 2020

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
Copy link
Member

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
Copy link

dave992 commented Jun 6, 2020

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
Copy link
Member

gavanderhoorn commented Jun 6, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants