Alignment prerejective tutorial, segmentation fault

[martinruenz]

Hey, running the alignment prerejective tutorial (http://pointclouds.org/documentation/tutorials/alignment_prerejective.php) on my system results in a segmentation fault.

Environment

• Operating System and version: Ubuntu 16.04.1 LTS
• Compiler: gcc 5.4
• PCL Version: master 8609873

Code to Reproduce

I used the code and point-clouds as provided in the tutorial.
The error happens within the

template <typename PointInT, typename PointNT, typename PointOutT> void
pcl::FPFHEstimationOMP<PointInT, PointNT, PointOutT>::computeFeature (PointCloudOut &output) function, see stack.

Output:

Failed to find match for field 'curvature'.
Failed to find match for field 'normal_x'.
Failed to find match for field 'normal_y'.
Failed to find match for field 'normal_z'.
Failed to find match for field 'curvature'.
The program has unexpectedly finished.

Stack:

1 _mm256_store_ps                                                                                                                                                                                                                                                                                                                                    avxintrin.h                854 0x7ffff788796a 
2  Eigen::internal::pstore<float, float __vector(8)>(float *, float __vector(8) const&)                                                                                                                                                                                                                                                               PacketMath.h               243 0x7ffff788796a 
3  Eigen::internal::pstoret<float, float __vector(8), 32>(float *, float __vector(8) const&)                                                                                                                                                                                                                                                          GenericPacketMath.h        486 0x7ffff788f63d 
4  Eigen::internal::assign_op<float>::assignPacket<32, float __vector(8)>(float *, float __vector(8) const&) const                                                                                                                                                                                                                                    AssignmentFunctors.h       28  0x7ffff788f63d 
5  Eigen::internal::generic_dense_assignment_kernel<Eigen::internal::evaluator<Eigen::Matrix<float, -1, 1, 0, -1, 1>>, Eigen::internal::evaluator<Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<float>, Eigen::Matrix<float, -1, 1, 0, -1, 1>>>, Eigen::internal::assign_op<float>, 0>::assignPacket<32, 32, float __vector(8)>(long)     AssignEvaluator.h          598 0x7ffff57a9087 
6  Eigen::internal::dense_assignment_loop<Eigen::internal::generic_dense_assignment_kernel<Eigen::internal::evaluator<Eigen::Matrix<float, -1, 1, 0, -1, 1>>, Eigen::internal::evaluator<Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<float>, Eigen::Matrix<float, -1, 1, 0, -1, 1>>>, Eigen::internal::assign_op<float>, 0>, 3, 0>::run AssignEvaluator.h          386 0x7ffff57a5fee 
7  Eigen::internal::call_dense_assignment_loop<Eigen::Matrix<float, -1, 1, 0, -1, 1>, Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<float>, Eigen::Matrix<float, -1, 1, 0, -1, 1>>, Eigen::internal::assign_op<float>>                                                                                                                    AssignEvaluator.h          653 0x7ffff57a2766 
8  Eigen::internal::Assignment<Eigen::Matrix<float, -1, 1, 0, -1, 1>, Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<float>, Eigen::Matrix<float, -1, 1, 0, -1, 1>>, Eigen::internal::assign_op<float>, Eigen::internal::Dense2Dense, float>::run                                                                                          AssignEvaluator.h          790 0x7ffff579f639 
9  Eigen::internal::call_assignment_no_alias<Eigen::Matrix<float, -1, 1, 0, -1, 1>, Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<float>, Eigen::Matrix<float, -1, 1, 0, -1, 1>>, Eigen::internal::assign_op<float>>                                                                                                                      AssignEvaluator.h          747 0x7ffff579c631 
10 Eigen::PlainObjectBase<Eigen::Matrix<float, -1, 1, 0, -1, 1>>::_set_noalias<Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<float>, Eigen::Matrix<float, -1, 1, 0, -1, 1>>>                                                                                                                                                              PlainObjectBase.h          700 0x7ffff5797e5a 
11 Eigen::PlainObjectBase<Eigen::Matrix<float, -1, 1, 0, -1, 1>>::PlainObjectBase<Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<float>, Eigen::Matrix<float, -1, 1, 0, -1, 1>>>                                                                                                                                                           PlainObjectBase.h          510 0x7ffff578a45c 
12 Eigen::Matrix<float, -1, 1, 0, -1, 1>::Matrix<Eigen::CwiseNullaryOp<Eigen::internal::scalar_constant_op<float>, Eigen::Matrix<float, -1, 1, 0, -1, 1>>>                                                                                                                                                                                            Matrix.h                   379 0x7ffff5787ee0 
13 _ZN3pcl17FPFHEstimationOMPINS_11PointNormalES1_NS_15FPFHSignature33EE14computeFeatureERNS_10PointCloudIS2_EE._omp_fn.99(void)                                                                                                                                                                                                                      fpfh_omp.hpp               141 0x7ffff2bb2485 
14 GOMP_parallel                                                                                                                                                                                                                                                                                                                                                                     0x7fffeb8a3cbf 
15 pcl::FPFHEstimationOMP<pcl::PointNormal, pcl::PointNormal, pcl::FPFHSignature33>::computeFeature                                                                                                                                                                                                                                                   fpfh_omp.hpp               119 0x7ffff2c7ccfe 
16 pcl::Feature<pcl::PointNormal, pcl::FPFHSignature33>::compute                                                                                                                                                                                                                                                                                      feature.hpp                220 0x550f71       
17 main                                                                                                                                                                                                                                                                                                                                               alignment_prerejective.cpp 74  0x548266       

[andersgb1]

What's your Eigen version?

[martinruenz]

The Eigen version is: 3.2.92

I forgot to mention earlier that I get the following warning when compiling:

In file included from /usr/local/include/pcl-1.8/pcl/sample_consensus/sac_model.h:52:0,
                 from /usr/local/include/pcl-1.8/pcl/sample_consensus/sac.h:45,
                 from /usr/local/include/pcl-1.8/pcl/sample_consensus/ransac.h:44,
                 from /usr/local/include/pcl-1.8/pcl/registration/icp.h:45,
                 from /home/martin/Documents/UCL/Code/Tests/PCL/alignment/alignment_prerejective.cpp:11:
/usr/local/include/pcl-1.8/pcl/sample_consensus/model_types.h: In function 'void __static_initialization_and_destruction_0(int, int)':
/usr/local/include/pcl-1.8/pcl/sample_consensus/model_types.h:99:3: warning: 'pcl::SAC_SAMPLE_SIZE' is deprecated: This map is deprecated and is kept only to prevent breaking existing user code. Starting from PCL 1.8.0 model sample size is a protected member of the SampleConsensusModel class [-Wdeprecated-declarations]
   SAC_SAMPLE_SIZE (sample_size_pairs, sample_size_pairs + sizeof (sample_size_pairs) / sizeof (SampleSizeModel));
   ^
/usr/local/include/pcl-1.8/pcl/sample_consensus/model_types.h:99:3: note: declared here 

[andersgb1]

I also get that warning, that's unrelated.

From your Eigen version I cannot see what the problem is then. Is there something special about your CPU architecture (the error seems to be in Eigen's use of Intel Intrinsics)?

[martinruenz]

Nothing too special I would say: Intel® Xeon(R) CPU E5-1620
I was running the example on my notebook yesterday and it also crashed -- I am not sure if it was the same reason, though. Could the issue be related Ubuntu 16?

[andersgb1]

Hmm, ok. Then unfortunately, I can't help out here. It doesn't seem to be related specifically to the tutorial code, but rather to glitches in the underlying code.

[martinruenz]

I just confirmed that the error on my notebook is the same (having an Intel i7 CPU). Do you have suggestions for a workaround? Did you try running the code in Ubuntu 16?

[andersgb1]

Yes, I've run it on my Ubuntu 16.04 x64 with GCC 5.4, but using PCL 1.8
(not master). If it makes any difference, I also compiled PCL in Release
mode instead of the default RelWIthDebInfo, but I doubt that makes a
difference.

Again, I'm not the one to suggest the solution for this, I'm afraid.

On Mon, Aug 22, 2016 at 3:11 PM, Martin Rünz [email protected]
wrote:

I just confirmed that the error on my notebook is the same (having an
Intel i7 CPU). Do you have suggestions for a workaround? Did you try
running the code in Ubuntu 16?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#1684 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADrOzZe1BGo0NmbnUPw9SklE9mipQm1yks5qiaAIgaJpZM4JpwEd
.

[SergioRAgostinho]

Could not reproduce the issue.

• Pcl version: current master c874d28
• OS: Mac OS X El Capitan 10.11.6
• Compiler: LLVM clang version 3.8.0
• Eigen: 3.2.8

[martinruenz]

@andersgb1 May I ask which Eigen version you have and whether you also use an Intel CPU?

I hope that I will find some time within the next days to dig a bit deeper into the problem.

[andersgb1]

Of course,

lscpu | grep 'Model name'
Model name: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz

dpkg -l | grep libeigen
ii libeigen3-dev 3.3~beta1-2
all lightweight C++
template library for linear algebra

On Tue, Aug 23, 2016 at 7:27 PM, Martin Rünz [email protected]
wrote:

@andersgb1 https://github.com/andersgb1 May I ask which Eigen version
you have and whether you also use an Intel CPU?

I hope that I will find some time within the next days to dig a bit deeper
into the problem.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1684 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADrOzb4Cgt2Wo4ZZJgnaGZkp2TELhDMQks5qiy2LgaJpZM4JpwEd
.

[martinruenz]

I just realised that the issue only appears when building the tutorial in debug mode.
Since the failing Eigen call is a very basic one -- like: Eigen::VectorXf t = Eigen::VectorXf::Zero (33);
in line 141 of fpfh_omp.hpp, see stack above -- I assumed that the issue might be related to the OpenMP parallelisation of the loop. As a test I just placed the line that I just posted as the first statement in the main.cpp. As predicted, the line did not lead to a crash there. But additionally, for some reason that is still unclear to me, the tutorial program didn't crash at all any more.
I still suspect that some missing Eigen initialisation causes the problem but calling Eigen::initParallel(); does not suffice and in fact, the problem is probably even not related to OpenMP, since removing the omp-pragma in computeFeature does also not resolve the issue.
@andersgb1 Would you mind trying to run the tutorial application in debug mode?

[rongfeng-china]

The same problem running the alignment_prejective tutorial.

[andersgb1]

I just compiled and ran the tutorial in Debug mode (PCL master still
compiled in Release, though) - made no difference, works fine on my side.

On Sat, Aug 27, 2016 at 6:32 PM, Martin Rünz [email protected]
wrote:

I just realised that the issue only appears when building the tutorial in
debug mode.
Since the failing Eigen call is a very basic one -- like: Eigen::VectorXf
t = Eigen::VectorXf::Zero (33);
in line 141 of fpfh_omp.hpp, see stack above -- I assumed that the issue
might be related to the OpenMP parallelisation of the loop. As a test I
just placed the line that I just posted as the first statement in the
main.cpp. As predicted, the line did not lead to a crash there. But
additionally, for some reason that is still unclear to me, the tutorial
program didn't crash at all any more.
I still suspect that some missing Eigen initialisation causes the problem
but calling Eigen::initParallel(); does not suffice and in fact, the
problem is probably even not related to OpenMP, since removing the
omp-pragma in computeFeature does also not resolve the issue.
@andersgb1 https://github.com/andersgb1 Would you mind trying to run
the tutorial application in debug mode?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1684 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADrOzZsWB8mTQ8v5ZJh9kr6oleBBsAb-ks5qkGabgaJpZM4JpwEd
.

[rongfeng-china]

It works with my Ubuntu14.04 laptop, but fails with another Ubuntu 16.04 one... Is the system version causing the failure?

[andersgb1]

I still think it's the Eigen version

On Wed, Sep 14, 2016 at 9:37 PM, happy_cat [email protected] wrote:

It works with my Ubuntu14.04 laptop, but fails with another Ubuntu 16.04
one... Is the system version causing the failure?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#1684 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADrOzQ5QHr0lkAGBVuByk23xg0F79v-Gks5qqEzkgaJpZM4JpwEd
.

[Ruturaj001]

I have same Eigen version as yours (libeigen3-dev 3.3~beta1-2). I am getting the same error.
PS: Running ubuntu 16.4.
Update: Downgraded to previous version of libgen and I am not getting segmentation fault anymore.

[phleba]

I have a similiar issue in a program using PCL 1.8, also with libeigen 3.3~beta1-2 (obviously shipped with Ubuntu 16.04). Colleagues of mine also experience this problem in other contexts and we were able to pinpoint it to a problem in alignment[0] and AVX optimization. I.e. if you compile it without -march=native (careful, maybe not the only optimization that causes this problem), it seems to work well. Since this problem seems to be introduced with the specific beta version of Eigen 3.3 I would be interested to know whether this is fixed in 3.3 or 3.3.1. Anyone try it out?

Edit: Tried it with 3.3 and 3.3.1 and it still crashes. So the only option seems to be a rollback to previous version or disabling of avx optimization.

[0] see here: https://eigen.tuxfamily.org/dox/group__DenseMatrixManipulation__Alignement.html

[rongfeng-china]

I'm also using Ubuntu 16.04... The same error...

[skramm]

I am having a similar problem with some related in-house code that crashes on some machines and not on others, event though all the build libraries are the same.
So to be sure I tried the tutorial code linked above, on local laptop, and also got a segfault at startup. However, this time it seems to be related to some boost code: lanczos_sum<long double> !

I'm posting this here just in case it can be useful...

• Test machine: Ubuntu 14.04, with Boost 1.54, Eigen 3.2.0, pcl 1.8, GCC 5.4.1

• compile with -g, ran with gdb, gives:
  Program received signal SIGSEGV, Segmentation fault.
0x00007fffe8cfc84c in lanczos_sum<long double> (z=<synthetic pointer>) at /usr/include/boost/math/special_functions/lanczos.hpp:897

• backtrace gives:

#0  0x00007fffe8cfc84c in lanczos_sum<long double> (z=<synthetic pointer>) at /usr/include/boost/math/special_functions/lanczos.hpp:897
#1  init (this=<optimized out>) at /usr/include/boost/math/special_functions/lanczos.hpp:49
#2  __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535) at /usr/include/boost/math/special_functions/lanczos.hpp:64
#3  _GLOBAL__sub_I_sac.cpp(void) () at /mnt/sda2/INSTALL_FILES/pcl-pcl-1.8.0/sample_consensus/src/sac.cpp:65
#4  0x00007ffff7dea10a in call_init (l=<optimized out>, argc=argc@entry=1, argv=argv@entry=0x7fffffffdd78, env=env@entry=0x7fffffffdd88) at dl-init.c:78
#5  0x00007ffff7dea1f3 in call_init (env=<optimized out>, argv=<optimized out>, argc=<optimized out>, l=<optimized out>) at dl-init.c:36
#6  _dl_init (main_map=0x7ffff7ffe1c8, argc=1, argv=0x7fffffffdd78, env=0x7fffffffdd88) at dl-init.c:126
#7  0x00007ffff7ddb30a in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
#8  0x0000000000000001 in ?? ()
#9  0x00007fffffffe130 in ?? ()
#10 0x0000000000000000 in ?? ()

[taketwo]

This Boost and lanczos stuff reminds me of #619.

[skramm]

My previous post above about crashing on the tutorial code is (somehow...) fixed. The problem appears ONLY when compiling with flags -std=c++11 or -std=c++14. By removing these flags, the program does not crash, so it's possibly either a GCC issue or a boost one. But I still have a segfault in my main app...

Ref: http://stackoverflow.com/a/28857548/193789

[skramm]

@taketwo Thanks, very useful link ! I'll try to rebuild everything with same C++ flags.

[tistatos]

I've had the similiar issue with PCL versions 1.8.0, 1.7.2 and master.
I tried to build all of the version above with different versions of Eigen since I guessed that were the issue was, but none of the versions I tried helped.

My final solution was to build PCL WITH -std=c++11 flag.
Eigen version was 3.3.3
GCC 5.4.1
Then everything worked.

[SergioRAgostinho]

@tistatos out of curiosity, was your Boost dependency compiled with c++11 support?

[tistatos]

@SergioRAgostinho - I'm using default boost packages from Linux Mint 18 Sarah 64-bit

Here is the apt-cache show info

Package: libboost-all-dev
Architecture: amd64
Source: boost-defaults
Version: 1.58.0.1ubuntu1

My approach to the problem was to only try with different combination of versions of PCL and Eigen since that's where my gdb debug output led me to. never tested with other versions of Boost

[SergioRAgostinho]

Can you all try the latest master version and provide some feedback on the results.

[y9luiz]

Someone solved this? i have the same problem,when i use the align() function this results in segmentation fault, some people said to me to remove the NaN values, but even after that the problem persists.

thanks for the help :)

[hugomilan]

I had a similar problem and could run the tutorial when I defined different meshes for the downsample part. However, I got different alignments (I think the one I got is wrong):

R = | -0.991 -0.101  0.092 | 
       | -0.136  0.707 -0.694 | 

t = < -0.499, 0.108, 0.290 >

I did the following for the beginning part of the algorithm:

  PointCloudT::Ptr object (new PointCloudT);
  PointCloudT::Ptr object_in (new PointCloudT);
  PointCloudT::Ptr object_aligned (new PointCloudT);
  PointCloudT::Ptr scene (new PointCloudT);
  PointCloudT::Ptr scene_in (new PointCloudT);
  FeatureCloudT::Ptr object_features (new FeatureCloudT);
  FeatureCloudT::Ptr scene_features (new FeatureCloudT);
  
  // Get input object and scene
  if (argc != 3)
  {
    pcl::console::print_error ("Syntax is: %s object.pcd scene.pcd\n", argv[0]);
    return (1);
  }
  
  // Load object and scene
  pcl::console::print_highlight ("Loading point clouds...\n");
  if (pcl::io::loadPCDFile<PointNT> (argv[1], *object_in) < 0 ||
      pcl::io::loadPCDFile<PointNT> (argv[2], *scene_in) < 0)
  {
    pcl::console::print_error ("Error loading object/scene file!\n");
    return (1);
  }
  
  // Downsample
  pcl::console::print_highlight ("Downsampling...\n");
  pcl::VoxelGrid<PointNT> grid;
  const float leaf = 0.005f;
  grid.setLeafSize (leaf, leaf, leaf);
  grid.setInputCloud (object_in);
  grid.filter (*object);
  grid.setInputCloud (scene_in);
  grid.filter (*scene);

[hrnr]

I have also hit the bug. I think the bug is not in Eigen or boost, but in PCL 1.8.1 Because:

• debian package v 1.8.1+dfsg1-2 have this bug reproducible always (for me) see https://tracker.debian.org/pkg/pcl
• I have compiled master as per 28e3f23 on the same machine with the same version of dependencies and that works fine.

So I think the status is fixed in master, needs new release.

[SergioRAgostinho]

We have some problems not properly exporting/not exporting the --march=native to the targets when PCL itself is compiled with that. That one is the most common culprit of random segfaults and this issue is likely another replica of that. We have #2100 hanging around, that will be pushed before the next release, plus #2239.

[hrnr]

I don't see how this might be the case. As the debian packages are built without -march=native all should be fine even if the user code is built with some vectorization.

[SergioRAgostinho]

If you give it a try with the current master, using the snippet provided in #2013, you'll see that's not necessarily true. Compile PCL passing -DCMAKE_CXX_FLAGS="-O2". Then compile the snippet in #2013 passing exactly -DCMAKE_CXX_FLAGS="-march=native". You'll still get the segfault.

Another user went deep into the problem while trying to understand his spurious segfaults you can read more about it here #1725.

[hrnr]

Thanks for the pointers, I'll try to investigate further on the affected machine.

[shengwenbo125]

I don't know the reason that the program built in one file runs well but the same program built under another file runs fault??

[taketwo]

This was reported back in 2016, when we did not export SSE flags properly. Therefore, self-compiled PCL (likely with -march=native) was interfaced with user code compiled without that flag. Hence segfaults.

One year later this was resolved with #1917. From that point on, those who self-compiled PCL and did not forget to add_definitions(${PCL_DEFINITIONS}) had no problems. Unfortunately, this very same PR missed a corner case, leading to -march=native flag being leaked into PCL packaged for Debian. So users like @hrnr started to have issues.

Now we have #2100 and it finally solves the issue for everyone, both those who compile themselves, and those who use packaged version. This will be a part of 1.9.0 release. We'll also try to re-release 1.8.1 since this is a serious problem, but I can not predict whether this will happen since I'm not a Debian maintainer.

[TouchDeeper]

Eigen version 3.3.5
PCL version 1.9.1, install option:

 cmake -DCMAKE_BUILD_TYPE=Release -DBUILD_GPU=ON -DBUILD_apps=ON -DBUILD_examples=ON -DBUILD_apps_3d_rec_framework=ON -DBUILD_apps_cloud_composer=ON -DBUILD_apps_in_hand_scanner=ON -DBUILD_apps_modeler=ON -DBUILD_apps_point_cloud_editor=ON -DBUILD_gpu_people=ON -DBUILD_gpu_surface=ON -DBUILD_gpu_tracking=ON -DBUILD_simulation=ON -DBUILD_global_tests=ON ..

CMakelist.txt

cmake_minimum_required(VERSION 3.9)
project(alignBug)

include_directories("/usr/local/include/eigen3" )

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

add_library(libalignbug SHARED bug_src.cpp)
add_executable(bug_test main.cpp )
target_link_libraries(bug_test
        ${PCL_LIBRARIES}
        libalignbug
        )

main.cpp

#include <Eigen/StdVector>
#include "bug_header.h"

int main(int argc, char** argv){
    DataProcessor data_processor;
    data_processor.LoadResult();
}

bug_src.cpp

#include "bug_header.h"

void DataProcessor::LoadResult() {
        FineRegistrationData fine_reg_data;
        Vec6 se3 = Vec6::Zero();
        fine_reg_data.se3s.emplace_back(se3);

        datas_.push_back(fine_reg_data);

}

bug_header.cpp

#ifndef BUG_HEADER_H
#define BUG_HEADER_H

#include <string>
#include <fstream>
#include <iostream>
#include <Eigen/Core>
typedef Eigen::Matrix<double, 6, 1> Vec6;
typedef std::vector<Vec6, Eigen::aligned_allocator<Vec6> > VecVec6;
struct FineRegistrationData{
    VecVec6 se3s;
};
class DataProcessor {
public:
    std::vector<FineRegistrationData> datas_;
    void LoadResult()
};
#endif //BUG_HEADER_H

gdb ./bug_test and backtrace output below information:

Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x41) at malloc.c:2951
2951    malloc.c: No such file or  directory.
(gdb) backtrace 
#0  __GI___libc_free (mem=0x41) at malloc.c:2951
#1  0x0000000000401ae9 in Eigen::internal::handmade_aligned_free (ptr=0x615c20) at /usr/local/include/eigen3/Eigen/src/Core/util/Memory.h:98
#2  0x0000000000401b04 in Eigen::internal::aligned_free (ptr=0x615c20) at /usr/local/include/eigen3/Eigen/src/Core/util/Memory.h:179
#3  0x0000000000402062 in Eigen::aligned_allocator<Eigen::Matrix<double, 6, 1, 0, 6, 1> >::deallocate (this=0x7fffffffcdb0, p=0x615c20)
    at /usr/local/include/eigen3/Eigen/src/Core/util/Memory.h:755
#4  0x000000000040200c in std::allocator_traits<Eigen::aligned_allocator<Eigen::Matrix<double, 6, 1, 0, 6, 1> > >::deallocate (__a=..., __p=0x615c20, __n=1)
---Type <return> to continue, or q <return> to quit---
    at /usr/include/c++/5/bits/alloc_traits.h:386
#5  0x0000000000401f8e in std::_Vector_base<Eigen::Matrix<double, 6, 1, 0, 6, 1>, Eigen::aligned_allocator<Eigen::Matrix<double, 6, 1, 0, 6, 1> > >::_M_deallocate (
    this=0x7fffffffcdb0, __p=0x615c20, __n=1) at /usr/include/c++/5/bits/stl_vector.h:178
#6  0x0000000000401edc in std::_Vector_base<Eigen::Matrix<double, 6, 1, 0, 6, 1>, Eigen::aligned_allocator<Eigen::Matrix<double, 6, 1, 0, 6, 1> > >::~_Vector_base (
    this=0x7fffffffcdb0, __in_chrg=<optimized out>) at /usr/include/c++/5/bits/stl_vector.h:160
#7  0x0000000000401e6b in std::vector<Eigen::Matrix<double, 6, 1, 0, 6, 1>, Eigen::aligned_allocator<Eigen::Matrix<double, 6, 1, 0, 6, 1> > >::~vector (this=0x7fffffffcdb0, 
---Type <return> to continue, or q <return> to quit---
    __in_chrg=<optimized out>) at /usr/include/c++/5/bits/stl_vector.h:425
#8  0x0000000000401e0c in FineRegistrationData::~FineRegistrationData (this=0x7fffffffcdb0, __in_chrg=<optimized out>)
    at /home/wang/imta_project/objectPoseEstimation/src/src/pose_estimation/include/bug_header.h:14
#9  0x00007ffff7bcf0a2 in DataProcessor::LoadResult (this=0x7fffffffce40) at /home/wang/imta_project/objectPoseEstimation/src/src/pose_estimation/src/bug_src.cpp:8
#10 0x0000000000401a1d in main (argc=1, argv=0x7fffffffcf58) at /home/wang/imta_project/objectPoseEstimation/src/src/pose_estimation/test/main.cpp:11

When I add below macro in main.cpp, code can run well, so I can sure it is the align problem.

#define EIGEN_DONT_VECTORIZE
#define EIGEN_DISABLE_UNALIGNED_ASSERT

When I comment the ${PCL_LIBRARIES}, code can run well.

Could you please provide some advice? Thanks a lot!

[taketwo]

What happens if you add the following?

target_link_libraries(libalignbug ${PCL_LIBRARIES})

[TouchDeeper]

Amazing,
target_link_libraries(libalignbug ${PCL_LIBRARIES}) works, could you please demonstrate the reason? Thanks a lot!

[JinXiangLai]

https://blog.csdn.net/wokaowokaowokao12345/article/details/51287011
this link can help you!

[YukunXia]

This was reported back in 2016, when we did not export SSE flags properly. Therefore, self-compiled PCL (likely with -march=native) was interfaced with user code compiled without that flag. Hence segfaults.

One year later this was resolved with #1917. From that point on, those who self-compiled PCL and did not forget to add_definitions(${PCL_DEFINITIONS}) had no problems. Unfortunately, this very same PR missed a corner case, leading to -march=native flag being leaked into PCL packaged for Debian. So users like @hrnr started to have issues.

Now we have #2100 and it finally solves the issue for everyone, both those who compile themselves, and those who use packaged version. This will be a part of 1.9.0 release. We'll also try to re-release 1.8.1 since this is a serious problem, but I can not predict whether this will happen since I'm not a Debian maintainer.

Hi @taketwo, I'm using PCL 1.10.0 on a Ubuntu 20.04 machine, and encountered segfault when -march=native was added to add_compile_options in my CMakeLists.txt. My program crashed immediately after a function executing pcl::PassThrough<pcl::PointXYZ> filtering was finished. If -march=native is removed, the program works well.

The function looks like

void update(const pcl::PointCloud<pcl::PointXYZ>::Ptr point_cloud) {
  pcl::PassThrough<pcl::PointXYZ> point_cloud_filter;
  point_cloud_filter.setInputCloud(point_cloud);
  point_cloud_filter.setFilterFieldName("z");
  point_cloud_filter.setFilterLimits(min_z, max_z);

  pcl::PointCloud<pcl::PointXYZ>::Ptr point_cloud_new(
      new pcl::PointCloud<pcl::PointXYZ>);
  point_cloud_filter.filter(*point_cloud_new);

gdb and backtrack shows lines starting with

(gdb) backtrace
#0  __GI___libc_free (mem=0xf121) at malloc.c:3102
#1  0x000055555556dad1 in boost::detail::sp_counted_impl_p<pcl::PointCloud<pcl::PointXYZ> >::dispose() ()
#2  0x000055555556848a in boost::detail::sp_counted_base::release() [clone .part.0] ()

Do you know how I can solve this problem?

[mvieth]

@YukunXia I assume you installed PCL via apt. Don't use -march=native in this case. The flags used in your own program and the flags used while building PCL have to fit together, else these kind of alignment problems occur. The apt package is not built with -march=native. As you wrote, if you don't use -march=native in your project, it works.

[YukunXia]

@YukunXia I assume you installed PCL via apt. Don't use -march=native in this case. The flags used in your own program and the flags used while building PCL have to fit together, else these kind of alignment problems occur. The apt package is not built with -march=native. As you wrote, if you don't use -march=native in your project, it works.

Thank you for your quick reply! Yeah, I installed PCL via apt, as recommended by PCL's website. I'll try installing PCL from scratch later.