Segmentation fault when using the PCL and Eigen libraries together.

[MarijaGolubovic]

Hello, We have encountered a segmentation fault when using the PCL and Eigen libraries together.

Initially, we found that a destructor defined in a header file caused the issue. Moving the destructor to the .cpp file resolved it temporarily. Later, the issue reappeared, this time inside the Eigen library with similar behavior.

The destructor seems to make an incorrect call to free(). When PCL is included (even just during compile time, without being used), it causes Eigen to call handmade_aligned_free(void* ptr) from Memory.h instead of the standard free(ptr). Setting the flag EIGEN_MALLOC_ALREADY_ALIGNED=1 resolved the issue, but caused compilation errors in modules that use PCL likely due to conflicting memory alignment assumptions and internal optimizations.

We found that moving the copy constructor to the .cpp file also resolves the issue with "double free or corruption (out)", similarly to how moving the destructor helped before. This suggests that inlining these functions in headers may be causing memory deallocation issues due to conflicting allocation mechanisms between PCL and Eigen.

Also, we encountered a double free or corruption (out) error, but the issue was resolved either by moving the copy constructor to the .cpp file or by setting the previously mentioned flag.

We've already tried suggestions from similar issues, but none have worked in our case.

A minimal example that reproduces the issue is attached.

System Info OS: Ubuntu 24.04 PCL version: 1.14.1 (also tested latest — same issue) Eigen version: Latest release C++ Standard: C++17 Build Tool: CMake

EigenError.zip

[larshg]

Its because PCL is build with AVX2 support and when you link it to your exe project, it forwards those flags. But your own library is not build with AVX2 support, so when the exe file pass in a vector type it allocated with aligned memory, but when its released in the library it get released as not being aligned.

if you add: target_compile_options(Wrapper PRIVATE /arch:AVX2) (windows edition - linux is -mavx2

then it works here.

[larshg]

Ohh ad nice reproduceable sample btw! Thanks for that.

[MarijaGolubovic]

Thanks for the quick reply! So just to make sure I am not missing anything.

1. If we are using other libraries that also rely on Eigen (e.g., OMPL, Pinocchio, FCL, etc.) and we exchange Eigen types between them, we should ensure all of them are compiled with the same flags (like -mavx2). Otherwise, we might run into similar memory alignment or deallocation issues. Is that correct?

2. On the other hand, if we disable those flags everywhere (e.g., for PCL, OMPL, and our own code), then the issue should go away as well (although we'd obviously lose out on the performance benefits). Does that sound right?

3. I tried building PCL without AVX and SSE like this:

cmake -DBUILD_examples=OFF \
      -DCMAKE_CXX_STANDARD=17 \
      -DCMAKE_CUDA_STANDARD=17 \
      -DPCL_ENABLE_MARCHNATIVE=OFF \
      -DPCL_ENABLE_SSE=OFF \
      -DPCL_ENABLE_AVX=OFF \
      ../

Is there anything else I should be disabling to fully remove all architecture-specific optimizations?

4. Lastly, when you distribute binaries (e.g., via apt install pcl-*), do you also disable AVX/SSE optimizations by default, since they are CPU-specific? Or are they enabled in the prebuilt packages?

Thanks again for the help. this clarifies a lot!