Segmentation fault using a custom point type with c++23, clang and libc++, when compiling for 32 bit

[Jimbopython]

Describe the bug

When using the example for a custom point type in the pcl documentation and compiling with c++23, clang, libc++ and compiling for 32 bit, i get a segmentation fault. When compiling with c++20 everything works fine. It also works fine, when using c++23, clang and libstdc++. It also always works fine in 64 bit.

To Reproduce

Compile the following example with c++23, clang and libc++ (and -m32):

#define PCL_NO_PRECOMPILE
#include <pcl/memory.h>
#include <pcl/pcl_macros.h>
#include <pcl/point_types.h>
#include <pcl/point_cloud.h>
#include <pcl/io/pcd_io.h>

struct EIGEN_ALIGN16 MyPointType    // enforce SSE padding for correct memory alignment
{
  PCL_ADD_POINT4D;                  // preferred way of adding a XYZ+padding
  float test;
  PCL_MAKE_ALIGNED_OPERATOR_NEW     // make sure our new allocators are aligned
};

POINT_CLOUD_REGISTER_POINT_STRUCT (MyPointType,           // here we assume a XYZ + "test" (as fields)
                                   (float, x, x)
                                   (float, y, y)
                                   (float, z, z)
                                   (float, test, test)
)


int
main (int argc, char** argv)
{
  pcl::PointCloud<MyPointType> cloud;
  cloud.resize (2);
  cloud.width = 2;
  cloud.height = 1;

  cloud[0].test = 1;
  cloud[1].test = 2;
  cloud[0].x = cloud[0].y = cloud[0].z = 0;
  cloud[1].x = cloud[1].y = cloud[1].z = 3;

  pcl::io::savePCDFile ("test.pcd", cloud);
}

Screenshots/Code snippets

Your Environment (please complete the following information):

• OS: Ubuntu 18.04
• Compiler: clang 18.1.8
• PCL Version 1.13.1

[mvieth]

@Jimbopython How did you install PCL? If you compiled it from source, did you change any options or did you use the default ones?
Which Eigen version do you have installed?
Do you use CMake to compile the example code? If yes, please post the CMakeLists.txt.
Can you add the following at the beginning of the main function and post the output: std::cout << EIGEN_MALLOC_ALREADY_ALIGNED << " " << EIGEN_DEFAULT_ALIGN_BYTES << " " << EIGEN_HAS_CXX17_OVERALIGN << " " << EIGEN_COMP_CXXVER << std::endl; (running in the situation where you get the segmentation fault)

[Jimbopython]

How did you install PCL? If you compiled it from source, did you change any options or did you use the default ones?

I am using conan to install PCL. The options in conan are:

"pcl/*:with_libusb": False,
"pcl/*:with_pcap": False,
"pcl/*:with_png": False,
"pcl/*:with_qhull": False,
"pcl/*:with_qt": False

Conan settings are:

[settings]
os=Linux
arch=x86
compiler=clang
compiler.version=18
compiler.libcxx=libc++
compiler.runtime=static
compiler.cppstd=23

[buildenv]
CC=/usr/bin/clang
CXX=/usr/bin/clang++

Toolchain file is:

set(CMAKE_SYSTEM_NAME Linux)
set(CMAKE_SYSTEM_PROCESSOR i386)

set(CMAKE_C_COMPILER clang -m32)
set(CMAKE_CXX_COMPILER clang++ -m32)

set(CMAKE_EXE_LINKER_FLAGS_INIT    "-fuse-ld=lld")
set(CMAKE_SHARED_LINKER_FLAGS_INIT "-fuse-ld=lld")
set(CMAKE_MODULE_LINKER_FLAGS_INIT "-fuse-ld=lld")

set(CMAKE_PREFIX_PATH "${CMAKE_PREFIX_PATH};/usr/lib/llvm-18")
set(CMAKE_FIND_ROOT_PATH "${CMAKE_FIND_ROOT_PATH};/usr/local/bin;/usr/local/lib")

If this is not enough info for you, i will have to dig into the cmake files conan generates to build PCL.

Which Eigen version do you have installed?

Eigen Version is 3.4.0

Do you use CMake to compile the example code? If yes, please post the CMakeLists.txt.

cmake_minimum_required(VERSION 3.6)
project(testPCL)

set(CMAKE_CXX_STANDARD 23)
find_package(PCL REQUIRED)

add_executable(testPCL main.cpp)
target_link_libraries(testPCL PRIVATE PCL::PCL)

find_library(LIBCXXABI_STATIC NAMES libc++abi.a REQUIRED)
find_library(LIBCXX_STATIC NAMES libc++.a REQUIRED)

target_link_options(testPCL
        PRIVATE
        $<$<LINK_LANGUAGE:CXX>:-stdlib=libc++ -static-libstdc++ -z nodelete>)
target_compile_options(testPCL
        PRIVATE
        $<$<COMPILE_LANGUAGE:CXX>:-stdlib=libc++>)
target_link_libraries(testPCL
        PRIVATE
        $<$<LINK_LANGUAGE:CXX>:libc++abi.a>)

The Cmake command line to build the sample is:

cmake -B /test/testPCL/build -S /test/testPCL -DCMAKE_BUILD_TYPE=Debug \
    -DCMAKE_TOOLCHAIN_FILE=cmake_toolchain_clang_i386.cmake \
    -DCMAKE_FIND_PACKAGE_PREFER_CONFIG=ON \
    -DCMAKE_PREFIX_PATH=/path/to/conan_generated_config_files && \
  cmake --build /test/testPCL/build

The mentioned toolchain file is the same as previously mentioned to compile PCL with conan.

Can you add the following at the beginning of the main function and post the output: std::cout << EIGEN_MALLOC_ALREADY_ALIGNED << " " << EIGEN_DEFAULT_ALIGN_BYTES << " " << EIGEN_HAS_CXX17_OVERALIGN << " " << EIGEN_COMP_CXXVER << std::endl; (running in the situation where you get the segmentation fault)

Output is: 0 16 1 20

[mvieth]

Due to your very specific build options, I was not (yet) able to reproduce the problem.

Eigen has a custom/"handmade" function to allocate and free aligned memory (useful e.g. for SSE). This is used in pcl::PointCloud via Eigen::aligned_allocator. Eigen first checks the required alignment (can be found in EIGEN_DEFAULT_ALIGN_BYTES), then checks whether malloc already fulfils this requirement (can be found in EIGEN_MALLOC_ALREADY_ALIGNED), and finally uses either malloc or Eigen::internal::handmade_aligned_malloc. The memory must then be freed with free or Eigen::internal::handmade_aligned_free, respectively. If there is a mismatch, a segmentation fault occurs. In the backtrace you posted, we see that Eigen::internal::handmade_aligned_free was used to release the memory. I suspect that for some reason, malloc (not Eigen::internal::handmade_aligned_malloc) was used to allocate it.

Please try running you program with valgrind. That should tell us with which function the memory was allocated.

And another question: is the pcl::io::savePCDFile ("test.pcd", cloud); necessary to make the segmentation fault appear?

[Jimbopython]

Please try running you program with valgrind. That should tell us with which function the memory was allocated.

==61302== Memcheck, a memory error detector
==61302== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==61302== Using Valgrind-3.25.0.GIT-5b2fed0f5a-20250111 and LibVEX; rerun with -h for copyright info
==61302== Command: ./build/testPCL
==61302== Parent PID: 1
==61302== 
--61302-- 
--61302-- Valgrind options:
--61302--    --leak-check=full
--61302--    --show-leak-kinds=all
--61302--    --track-origins=yes
--61302--    --verbose
--61302--    --log-file=valgrind-out1.txt
--61302-- Contents of /proc/version:
--61302--   Linux version 6.11.11-1-MANJARO (linux611@manjaro) (gcc (GCC) 14.2.1 20240910, GNU ld (GNU Binutils) 2.43.0) #1 SMP PREEMPT_DYNAMIC Thu, 05 Dec 2024 16:26:44 +0000
--61302-- 
--61302-- Arch and hwcaps: X86, LittleEndian, x86-mmxext-sse1-sse2-sse3-lzcnt
--61302-- Page sizes: currently 4096, max supported 4096
--61302-- Valgrind library directory: /usr/local/libexec/valgrind
--61302-- Reading syms from /test/testPCL/build/testPCL
--61302-- Reading syms from /lib/i386-linux-gnu/ld-2.27.so
--61302--   Considering /lib/i386-linux-gnu/ld-2.27.so ..
--61302--   .. CRC mismatch (computed ec847075 wanted 5f92a687)
--61302--   Considering /usr/lib/debug/lib/i386-linux-gnu/ld-2.27.so ..
--61302--   .. CRC is valid
--61302-- Reading syms from /usr/local/libexec/valgrind/memcheck-x86-linux
--61302--    object doesn't have a dynamic symbol table
--61302-- Scheduler: using generic scheduler lock implementation.
--61302-- Reading suppressions file: /usr/local/libexec/valgrind/default.supp
==61302== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-61302-by-???-on-5cc251ea76c3
==61302== embedded gdbserver: writing to   /tmp/vgdb-pipe-to-vgdb-from-61302-by-???-on-5cc251ea76c3
==61302== embedded gdbserver: shared mem   /tmp/vgdb-pipe-shared-mem-vgdb-61302-by-???-on-5cc251ea76c3
==61302== 
==61302== TO CONTROL THIS PROCESS USING vgdb (which you probably
==61302== don't want to do, unless you know exactly what you're doing,
==61302== or are doing some strange experiment):
==61302==   /usr/local/libexec/valgrind/../../bin/vgdb --pid=61302 ...command...
==61302== 
==61302== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==61302==   /path/to/gdb ./build/testPCL
==61302== and then give GDB the following command
==61302==   target remote | /usr/local/libexec/valgrind/../../bin/vgdb --pid=61302
==61302== --pid is optional if only one valgrind process is running
==61302== 
--61302-- REDIR: 0x401b560 (ld-linux.so.2:strlen) redirected to 0x580e1a6f (vgPlain_x86_linux_REDIR_FOR_strlen)
--61302-- REDIR: 0x401b2c0 (ld-linux.so.2:index) redirected to 0x580e1a4a (vgPlain_x86_linux_REDIR_FOR_index)
--61302-- Reading syms from /usr/local/libexec/valgrind/vgpreload_core-x86-linux.so
--61302-- Reading syms from /usr/local/libexec/valgrind/vgpreload_memcheck-x86-linux.so
==61302== WARNING: new redirection conflicts with existing -- ignoring it
--61302--     old: 0x0401b560 (strlen              ) R-> (0000.0) 0x580e1a6f vgPlain_x86_linux_REDIR_FOR_strlen
--61302--     new: 0x0401b560 (strlen              ) R-> (2007.0) 0x048397a0 strlen
--61302-- Reading syms from /usr/lib/libc++.so.1.0
--61302-- Reading syms from /usr/lib/i386-linux-gnu/libc++abi.so.1.0
--61302-- Reading syms from /lib/i386-linux-gnu/librt-2.27.so
--61302-- Reading syms from /lib/i386-linux-gnu/libpthread-2.27.so
--61302--   Considering /usr/lib/debug/.build-id/03/20e4af3034dd1e0bdb503111d036a724b086b1.debug ..
--61302--   .. build-id is valid
--61302-- Reading syms from /lib/i386-linux-gnu/libm-2.27.so
--61302-- Reading syms from /lib/i386-linux-gnu/libgcc_s.so.1
--61302-- Reading syms from /lib/i386-linux-gnu/libc-2.27.so
--61302--   Considering /lib/i386-linux-gnu/libc-2.27.so ..
--61302--   .. CRC mismatch (computed 54ff02d8 wanted 2fc8b243)
--61302--   Considering /usr/lib/debug/lib/i386-linux-gnu/libc-2.27.so ..
--61302--   .. CRC is valid
==61302== WARNING: new redirection conflicts with existing -- ignoring it
--61302--     old: 0x04b5cb30 (memalign            ) R-> (1011.0) 0x04838162 memalign
--61302--     new: 0x04b5cb30 (memalign            ) R-> (1017.0) 0x048388a1 aligned_alloc
==61302== WARNING: new redirection conflicts with existing -- ignoring it
--61302--     old: 0x04b5cb30 (memalign            ) R-> (1011.0) 0x04838162 memalign
--61302--     new: 0x04b5cb30 (memalign            ) R-> (1017.0) 0x04838760 aligned_alloc
==61302== WARNING: new redirection conflicts with existing -- ignoring it
--61302--     old: 0x04b5cb30 (memalign            ) R-> (1011.0) 0x04838162 memalign
--61302--     new: 0x04b5cb30 (memalign            ) R-> (1017.0) 0x048388a1 aligned_alloc
==61302== WARNING: new redirection conflicts with existing -- ignoring it
--61302--     old: 0x04b5cb30 (memalign            ) R-> (1011.0) 0x04838162 memalign
--61302--     new: 0x04b5cb30 (memalign            ) R-> (1017.0) 0x04838760 aligned_alloc
--61302-- Reading syms from /usr/lib/i386-linux-gnu/libatomic.so.1.2.0
--61302-- REDIR: 0x4b60be0 (libc.so.6:strncasecmp) redirected to 0x482a55a (_vgnU_ifunc_wrapper)
--61302-- REDIR: 0x4b67060 (libc.so.6:memrchr) redirected to 0x482a55a (_vgnU_ifunc_wrapper)
--61302-- REDIR: 0x4b7ac10 (libc.so.6:wcslen) redirected to 0x482a55a (_vgnU_ifunc_wrapper)
--61302-- REDIR: 0x4b604e0 (libc.so.6:strstr) redirected to 0x483f1c0 (strstr)
--61302-- REDIR: 0x4b79df0 (libc.so.6:__GI_strrchr) redirected to 0x4838f80 (__GI_strrchr)
--61302-- REDIR: 0x4b609a0 (libc.so.6:memset) redirected to 0x482a55a (_vgnU_ifunc_wrapper)
--61302-- REDIR: 0x4c211c0 (libc.so.6:__memset_sse2) redirected to 0x483df30 (memset)
--61302-- REDIR: 0x4b79470 (libc.so.6:__GI_memchr) redirected to 0x483ad40 (__GI_memchr)
--61302-- REDIR: 0x4b79980 (libc.so.6:__GI_memmove) redirected to 0x483e370 (__GI_memmove)
--61302-- REDIR: 0x4b62600 (libc.so.6:strchrnul) redirected to 0x483eb20 (strchrnul)
--61302-- REDIR: 0x4b5bfb0 (libc.so.6:malloc) redirected to 0x48316e8 (malloc)
--61302-- REDIR: 0x4b5fba0 (libc.so.6:strlen) redirected to 0x482a55a (_vgnU_ifunc_wrapper)
--61302-- REDIR: 0x4b67390 (libc.so.6:__strlen_sse2_bsf) redirected to 0x4839700 (strlen)
--61302-- REDIR: 0x4b799f0 (libc.so.6:__GI_mempcpy) redirected to 0x483ed50 (__GI_mempcpy)
--61302-- REDIR: 0x4981ff0 (???:operator new(unsigned int, std::align_val_t)) redirected to 0x483231e (operator new(unsigned int, std::align_val_t))
==61302== Invalid read of size 4
==61302==    at 0x10F1B9: Eigen::internal::handmade_aligned_free(void*) (Memory.h:118)
==61302==    by 0x10F17E: Eigen::internal::aligned_free(void*) (Memory.h:206)
==61302==    by 0x10F154: Eigen::aligned_allocator<MyPointType>::deallocate(MyPointType*, unsigned int) (Memory.h:921)
==61302==    by 0x10EFB7: std::__1::allocator_traits<Eigen::aligned_allocator<MyPointType> >::deallocate[abi:ne180100](Eigen::aligned_allocator<MyPointType>&, MyPointType*, unsigned int) (allocator_traits.h:289)
==61302==    by 0x10EEFE: std::__1::vector<MyPointType, Eigen::aligned_allocator<MyPointType> >::__destroy_vector::operator()[abi:ne180100]() (vector:492)
==61302==    by 0x10DCF1: std::__1::vector<MyPointType, Eigen::aligned_allocator<MyPointType> >::~vector[abi:ne180100]() (vector:501)
==61302==    by 0x10DA39: pcl::PointCloud<MyPointType>::~PointCloud() (point_cloud.h:172)
==61302==    by 0x10D59B: main (main.cpp:40)
==61302==  Address 0x4cc846c is 4 bytes before a block of size 64 alloc'd
==61302==    at 0x48323FF: operator new(unsigned int, std::align_val_t) (vg_replace_malloc.c:540)
==61302==    by 0x110EEA: void* std::__1::__libcpp_operator_new[abi:ne180100]<unsigned int, std::align_val_t>(unsigned int, std::align_val_t) (new:271)
==61302==    by 0x110E6E: std::__1::__libcpp_allocate[abi:ne180100](unsigned int, unsigned int) (new:290)
==61302==    by 0x110D7A: std::__1::allocator<MyPointType>::allocate[abi:ne180100](unsigned int) (allocator.h:125)
==61302==    by 0x110D03: std::__1::allocator<MyPointType>::allocate_at_least[abi:ne180100](unsigned int) (allocator.h:131)
==61302==    by 0x110CB6: std::__1::allocation_result<std::__1::allocator_traits<Eigen::aligned_allocator<MyPointType> >::pointer> std::__1::allocate_at_least[abi:ne180100]<Eigen::aligned_allocator<MyPointType> >(Eigen::aligned_allocator<MyPointType>&, unsigned int) (allocate_at_least.h:34)
==61302==    by 0x110BE6: auto std::__1::__allocate_at_least[abi:ne180100]<Eigen::aligned_allocator<MyPointType> >(Eigen::aligned_allocator<MyPointType>&, unsigned int) (allocate_at_least.h:42)
==61302==    by 0x1102F8: std::__1::__split_buffer<MyPointType, Eigen::aligned_allocator<MyPointType>&>::__split_buffer(unsigned int, unsigned int, Eigen::aligned_allocator<MyPointType>&) (__split_buffer:343)
==61302==    by 0x10FFE9: std::__1::vector<MyPointType, Eigen::aligned_allocator<MyPointType> >::__append(unsigned int) (vector:1095)
==61302==    by 0x10FEC0: std::__1::vector<MyPointType, Eigen::aligned_allocator<MyPointType> >::resize(unsigned int) (vector:1750)
==61302==    by 0x10D9A0: pcl::PointCloud<MyPointType>::resize(unsigned int) (point_cloud.h:464)
==61302==    by 0x10D424: main (main.cpp:30)
==61302== 
--61302-- REDIR: 0x4b5c5e0 (libc.so.6:free) redirected to 0x48342b6 (free)
==61302== 
==61302== HEAP SUMMARY:
==61302==     in use at exit: 64 bytes in 1 blocks
==61302==   total heap usage: 2 allocs, 1 frees, 1,088 bytes allocated
==61302== 
==61302== Searching for pointers to 1 not-freed blocks
==61302== Checked 121,164 bytes
==61302== 
==61302== 64 bytes in 1 blocks are definitely lost in loss record 1 of 1
==61302==    at 0x48323FF: operator new(unsigned int, std::align_val_t) (vg_replace_malloc.c:540)
==61302==    by 0x110EEA: void* std::__1::__libcpp_operator_new[abi:ne180100]<unsigned int, std::align_val_t>(unsigned int, std::align_val_t) (new:271)
==61302==    by 0x110E6E: std::__1::__libcpp_allocate[abi:ne180100](unsigned int, unsigned int) (new:290)
==61302==    by 0x110D7A: std::__1::allocator<MyPointType>::allocate[abi:ne180100](unsigned int) (allocator.h:125)
==61302==    by 0x110D03: std::__1::allocator<MyPointType>::allocate_at_least[abi:ne180100](unsigned int) (allocator.h:131)
==61302==    by 0x110CB6: std::__1::allocation_result<std::__1::allocator_traits<Eigen::aligned_allocator<MyPointType> >::pointer> std::__1::allocate_at_least[abi:ne180100]<Eigen::aligned_allocator<MyPointType> >(Eigen::aligned_allocator<MyPointType>&, unsigned int) (allocate_at_least.h:34)
==61302==    by 0x110BE6: auto std::__1::__allocate_at_least[abi:ne180100]<Eigen::aligned_allocator<MyPointType> >(Eigen::aligned_allocator<MyPointType>&, unsigned int) (allocate_at_least.h:42)
==61302==    by 0x1102F8: std::__1::__split_buffer<MyPointType, Eigen::aligned_allocator<MyPointType>&>::__split_buffer(unsigned int, unsigned int, Eigen::aligned_allocator<MyPointType>&) (__split_buffer:343)
==61302==    by 0x10FFE9: std::__1::vector<MyPointType, Eigen::aligned_allocator<MyPointType> >::__append(unsigned int) (vector:1095)
==61302==    by 0x10FEC0: std::__1::vector<MyPointType, Eigen::aligned_allocator<MyPointType> >::resize(unsigned int) (vector:1750)
==61302==    by 0x10D9A0: pcl::PointCloud<MyPointType>::resize(unsigned int) (point_cloud.h:464)
==61302==    by 0x10D424: main (main.cpp:30)
==61302== 
==61302== LEAK SUMMARY:
==61302==    definitely lost: 64 bytes in 1 blocks
==61302==    indirectly lost: 0 bytes in 0 blocks
==61302==      possibly lost: 0 bytes in 0 blocks
==61302==    still reachable: 0 bytes in 0 blocks
==61302==         suppressed: 0 bytes in 0 blocks
==61302== 
==61302== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
==61302== 
==61302== 1 errors in context 1 of 2:
==61302== Invalid read of size 4
==61302==    at 0x10F1B9: Eigen::internal::handmade_aligned_free(void*) (Memory.h:118)
==61302==    by 0x10F17E: Eigen::internal::aligned_free(void*) (Memory.h:206)
==61302==    by 0x10F154: Eigen::aligned_allocator<MyPointType>::deallocate(MyPointType*, unsigned int) (Memory.h:921)
==61302==    by 0x10EFB7: std::__1::allocator_traits<Eigen::aligned_allocator<MyPointType> >::deallocate[abi:ne180100](Eigen::aligned_allocator<MyPointType>&, MyPointType*, unsigned int) (allocator_traits.h:289)
==61302==    by 0x10EEFE: std::__1::vector<MyPointType, Eigen::aligned_allocator<MyPointType> >::__destroy_vector::operator()[abi:ne180100]() (vector:492)
==61302==    by 0x10DCF1: std::__1::vector<MyPointType, Eigen::aligned_allocator<MyPointType> >::~vector[abi:ne180100]() (vector:501)
==61302==    by 0x10DA39: pcl::PointCloud<MyPointType>::~PointCloud() (point_cloud.h:172)
==61302==    by 0x10D59B: main (main.cpp:40)
==61302==  Address 0x4cc846c is 4 bytes before a block of size 64 alloc'd
==61302==    at 0x48323FF: operator new(unsigned int, std::align_val_t) (vg_replace_malloc.c:540)
==61302==    by 0x110EEA: void* std::__1::__libcpp_operator_new[abi:ne180100]<unsigned int, std::align_val_t>(unsigned int, std::align_val_t) (new:271)
==61302==    by 0x110E6E: std::__1::__libcpp_allocate[abi:ne180100](unsigned int, unsigned int) (new:290)
==61302==    by 0x110D7A: std::__1::allocator<MyPointType>::allocate[abi:ne180100](unsigned int) (allocator.h:125)
==61302==    by 0x110D03: std::__1::allocator<MyPointType>::allocate_at_least[abi:ne180100](unsigned int) (allocator.h:131)
==61302==    by 0x110CB6: std::__1::allocation_result<std::__1::allocator_traits<Eigen::aligned_allocator<MyPointType> >::pointer> std::__1::allocate_at_least[abi:ne180100]<Eigen::aligned_allocator<MyPointType> >(Eigen::aligned_allocator<MyPointType>&, unsigned int) (allocate_at_least.h:34)
==61302==    by 0x110BE6: auto std::__1::__allocate_at_least[abi:ne180100]<Eigen::aligned_allocator<MyPointType> >(Eigen::aligned_allocator<MyPointType>&, unsigned int) (allocate_at_least.h:42)
==61302==    by 0x1102F8: std::__1::__split_buffer<MyPointType, Eigen::aligned_allocator<MyPointType>&>::__split_buffer(unsigned int, unsigned int, Eigen::aligned_allocator<MyPointType>&) (__split_buffer:343)
==61302==    by 0x10FFE9: std::__1::vector<MyPointType, Eigen::aligned_allocator<MyPointType> >::__append(unsigned int) (vector:1095)
==61302==    by 0x10FEC0: std::__1::vector<MyPointType, Eigen::aligned_allocator<MyPointType> >::resize(unsigned int) (vector:1750)
==61302==    by 0x10D9A0: pcl::PointCloud<MyPointType>::resize(unsigned int) (point_cloud.h:464)
==61302==    by 0x10D424: main (main.cpp:30)
==61302== 
==61302== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)

For this test i linked the runtime dynamically.
I am curious. Why is this only happening when resizing?

And another question: is the pcl::io::savePCDFile ("test.pcd", cloud); necessary to make the segmentation fault appear?

The segmentation fault also appears without this line. Specifically. the valgrind output from above is from a binary compiled without this line.

[mvieth]

Perfect, that is the output I was looking for. So pcl::PointCloud<MyPointType>::resize leads to std::allocator<MyPointType>::allocate_at_least and finally operator new (but not Eigen::internal::handmade_aligned_alloc, which would be correct).

This is a really interesting problem. 😄

Eigen::aligned_allocator (used by the points member of pcl::PointCloud) does not implement the allocate_at_least function ( https://gitlab.com/libeigen/eigen/-/blob/master/Eigen/src/Core/util/Memory.h#L947 ). But it inherits from std::allocator, which does implement allocate_at_least. However, the problem occurs because std::allocator::allocate_at_least is used to allocate the memory and Eigen::aligned_allocator::deallocate is used to free it.
I think Eigen::aligned_allocator has to implement allocate_at_least to work properly in this situation. I will do some further tests and then open an issue in the Eigen project.

It seems that only libc++ uses allocate_at_least when resizing a vector, while libstdc++ (currently) does not (as far as I was able to see in the libstdc++ code). That is likely why the problem does not happen when you switch to libstdc++.

allocate_at_least was introduced in c++23. That is why you only observe the problem when compiling as c++23, but not as c++20.

Why does it work fine if you switch to 64 bit? I mentioned in my last comment that Eigen first checks whether malloc already delivers the desired alignment, based on architecture etc. In your 32 bit test, this was not the case, as shown by EIGEN_MALLOC_ALREADY_ALIGNED==0. I believe, with 64 bit this is instead EIGEN_MALLOC_ALREADY_ALIGNED==1, so then free is used instead of Eigen::internal::handmade_aligned_free, and the segmentation fault does not happen.

I am not sure if there are any work-arounds until Eigen::aligned_allocator is fixed (other than using libstdc++, c++20, and/or 64 bit of course - not sure if one of these is acceptable for your case). You could try defining EIGEN_DONT_VECTORIZE so that Eigen hopefully sets EIGEN_DEFAULT_ALIGN_BYTES to zero (see https://eigen.tuxfamily.org/dox/TopicPreprocessorDirectives.html and https://gitlab.com/libeigen/eigen/-/blob/master/Eigen/src/Core/util/ConfigureVectorization.h ).

I am curious. Why is this only happening when resizing?

If the point cloud stays at zero points, there is no memory allocated, and no memory has to be freed at the end. I would assume though that the same problem happens with, e.g., reserve.

[mvieth]

For your information: https://gitlab.com/libeigen/eigen/-/issues/2895