koide3/ndt_omp

Segmentation fault (core dumped) with PCL 1.8

qmx066 opened this issue · 11 comments

hey there, i'm compiling this tool with PCL version 1.8, Segfault really annoys me so much, no matter release or debug, when setinputtarget() function called, it crashes with segfault. and pcl 1.7 can make it work well (release or debug), do you have any ideas about that?

Hi @qmx066 ,

Do you see the segfault with the standard NDT in pcl?

Hi @qmx066 ,

Do you see the segfault with the standard NDT in pcl?

nope, the standard NDT works fine. as workaround, i'm now running with PCL 1.7, the problem with 1.8 still confuses.

On my PC, it works with pcl1.8 apt binary on Ubuntu 18.04. I suppose it may be some problem relating to SSE optimization. Could you try to remove the SSE options in CMakeLists?

add_definitions(-std=c++11 -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2)

set(CMAKE_CXX_FLAGS "-std=c++11 -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2")

Hi, I have the exact same problem using PCL 1.9.1 on ubuntu 16.04. The pcl::NormalDistributionTransform works good but a segmentation fault occurs with the pclomp::NormalDistributionTransform when I call for the setinputtarget(). This also occurs with the pclomp::GeneralizedIterativeClosestPoint class.
Do you have any idea if this bug is solvable since I might need to use other features only available in PCL 1.9 ?

On my PC, it works with pcl1.8 apt binary on Ubuntu 18.04. I suppose it may be some problem relating to SSE optimization. Could you try to remove the SSE options in CMakeLists?

ndt_omp/CMakeLists.txt

Line 5 in e956da1
add_definitions(-std=c++11 -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2)

ndt_omp/CMakeLists.txt

Line 6 in e956da1
set(CMAKE_CXX_FLAGS "-std=c++11 -msse -msse2 -msse3 -msse4 -msse4.1 -msse4.2")

hi koide3, it doesn't fix my problem, no matter add these or not, the fault occurs all the time.

Hi, I have the exact same problem using PCL 1.9.1 on ubuntu 16.04. The pcl::NormalDistributionTransform works good but a segmentation fault occurs with the pclomp::NormalDistributionTransform when I call for the setinputtarget(). This also occurs with the pclomp::GeneralizedIterativeClosestPoint class.
Do you have any idea if this bug is solvable since I might need to use other features only available in PCL 1.9 ?

i'm lucky that PCL 1.7 can be used in my situation.

Boost library PCL used is not ABI compatible between C++03 and C++11. So if you can try do not use -std=c++11.

I have the same problem using PCL 1.9.1 on ubuntu 16.04.
there are two pcl versions on my PC, one is PCL 1.9.1(compiled installation),the other is pcl 1.7 installed from ROS.
This problem may be a pcl1.9 bug.
a solution can be useful in helping you:
Comment out these lines in CMakeLists.txt:

#find_package(PCL 1.7 REQUIRED)
#include_directories(${PCL_INCLUDE_DIRS})
#link_directories(${PCL_LIBRARY_DIRS})
#add_definitions(${PCL_DEFINITIONS})

I hope it works for you.

@zhkai929 , Thank you, it solved my problem. There are two pcl version on my pc, one is pcl1.7 installed from ros, and another is pcl1.8 installed by myself from github, it really give me a big help!

@zhkai929 , Thank you, it solved my problem. There are two pcl version on my pc, one is pcl1.7 installed from ros, and another is pcl1.8 installed by myself from github, it really give me a big help!

Hello, i also met the same problem, but pcl 1.9 instead of pcl 1.8. The above solution is not work for me.
where was pcl 1.8 installed , usr local or others?

At me, on ubuntu 18.04 + pcl 1.8 all is normal, but the system is upgraded to ubuntu 20.04 + pcl 1.10, there occurs one new segmentation fault. run the same source and target pointcloud, it can work with the align app, but not in my code program ros callback... through backtrace, I find https://github.com/koide3/ndt_omp/blob/master/include/pclomp/voxel_grid_covariance_omp_impl.hpp#L99 leaves_.clear() has some wrong, gdb shows that std::_Rb_tree::M_erase segmention fault, below picture is as show in detail:
ndt_omp rb_tree段错误
with my many debug, it seem can work in one single process while in multi thread.so I doubt this is caused by std::map is unsafe in multi threads!