GreedyProjectionTriangulation destructor crash under Windows/MSYS2

[edwardpier]

The example code given here: https://pcl.readthedocs.io/projects/tutorials/en/master/greedy_projection.html#greedy-triangulation crashes when the gp3 GreedyProjectionTriangulation object is destructed at the end of execution.

I have compiled PCL myself under MSYS2 on Windows 10 using GCC: cmake -G "MSYS Makefiles" This happens with the current version of PCL in the git repo as well as the version tagged pcl-1.14.0

Here is a gdb stack trace:

warning: Critical error detected c0000374

Thread 1 received signal SIGTRAP, Trace/breakpoint trap.
0x00007ffa6172f2d3 in ntdll!RtlIsZeroMemory () from /c/Windows/SYSTEM32/ntdll.dll
(gdb) bt
#0  0x00007ffa6172f2d3 in ntdll!RtlIsZeroMemory () from /c/Windows/SYSTEM32/ntdll.dll
#1  0x00007ffa61738092 in ntdll!RtlpNtSetValueKey () from /c/Windows/SYSTEM32/ntdll.dll
#2  0x00007ffa6173837a in ntdll!RtlpNtSetValueKey () from /c/Windows/SYSTEM32/ntdll.dll
#3  0x00007ffa6173e001 in ntdll!RtlpNtSetValueKey () from /c/Windows/SYSTEM32/ntdll.dll
#4  0x00007ffa61655bf0 in ntdll!RtlGetCurrentServiceSessionId () from /c/Windows/SYSTEM32/ntdll.dll
#5  0x00007ffa616547b1 in ntdll!RtlFreeHeap () from /c/Windows/SYSTEM32/ntdll.dll
#6  0x00007ffa61189c9c in msvcrt!free () from /c/Windows/System32/msvcrt.dll
#7  0x00007ff684faabd8 in Eigen::internal::aligned_free (ptr=0x701340)
    at C:/msys64/mingw64/include/eigen3/Eigen/src/Core/util/Memory.h:203
#8  0x00007ff684fa9e60 in Eigen::aligned_allocator<Eigen::Matrix<float, 3, 1, 0, 3, 1> >::deallocate (this=0x5ff9d8, p=0x701340) at C:/msys64/mingw64/include/eigen3/Eigen/src/Core/util/Memory.h:921
#9  0x00007ff684fb7a2b in std::allocator_traits<Eigen::aligned_allocator<Eigen::Matrix<float, 3, 1, 0, 3, 1> > >::deallocate (__a=..., __p=0x701340, __n=397)
    at C:/msys64/mingw64/include/c++/13.2.0/bits/alloc_traits.h:360
#10 0x00007ff684fb4582 in std::_Vector_base<Eigen::Matrix<float, 3, 1, 0, 3, 1>, Eigen::aligned_allocator<Eigen::Matrix<float, 3, 1, 0, 3, 1> > >::_M_deallocate (this=0x5ff9d8, __p=0x701340, __n=397)
    at C:/msys64/mingw64/include/c++/13.2.0/bits/stl_vector.h:387
#11 0x00007ff684fb4639 in std::_Vector_base<Eigen::Matrix<float, 3, 1, 0, 3, 1>, Eigen::aligned_allocator<Eigen::Matrix<float, 3, 1, 0, 3, 1> > >::~_Vector_base (this=0x5ff9d8,
    __in_chrg=<optimized out>) at C:/msys64/mingw64/include/c++/13.2.0/bits/stl_vector.h:366
#12 0x00007ff684fb9981 in std::vector<Eigen::Matrix<float, 3, 1, 0, 3, 1>, Eigen::aligned_allocator<Eigen::Matrix<float, 3, 1, 0, 3, 1> > >::~vector (this=0x5ff9d8, __in_chrg=<optimized out>)
    at C:/msys64/mingw64/include/c++/13.2.0/bits/stl_vector.h:735
#13 0x00007ff684fa61ca in pcl::GreedyProjectionTriangulation<pcl::PointNormal>::~GreedyProjectionTriangulation (this=0x5ff940, __in_chrg=<optimized out>)
    at C:/Program Files (x86)/PCL/include/pcl-1.14/pcl/surface/gp3.h:131

My best guess after reading
surface/include/pcl/surface/gp3.h surface/include/pcl/surface/impl/gp3.hpp is that there is an issue with the coords_ member variable of the GreedyProjectionTriangulation class.

I do not have this problem under Ubuntu 20.04 with PCL 1.10.0 installed out of apt. Comparing surface/include/pcl/surface/impl/gp3.hpp between 1.10.0 and 1.40.0 I see that there was a change in the way coords_ is filled:

<     coords_.push_back(input_->points[(*indices_)[cp]].getVector3fMap());
>     coords_.push_back((*input_)[(*indices_)[cp]].getVector3fMap());

but I don't know the code well enough to know if this is a red herring.

[mvieth]

Hi, thanks for the very informative issue description. I agree that the problem seems to be related to the coords_ member, but the changed line you mentioned is unlikely to be the cause. Rather than the different PCL versions, the important difference is probably the different installation methods (apt vs self-compiled) and different compiler options used. Usually, we see problems with Eigen::internal::aligned_free in one of two cases:

• PCL was compiled as C++14 and the own code was compiled as C++17, or vice versa. This should be solved in PCL 1.14.0, but it may still be worth it to make sure that you use the same C++ standard everywhere consistently
• different SIMD options (SSE, AVX) enabled while building PCL vs building your own code. Relevant PCL CMake options are: PCL_ENABLE_SSE, PCL_ENABLE_AVX, PCL_ENABLE_MARCHNATIVE. These are ON by default, the last one is ON if the system is a UNIX, so I am unsure how the behaviour is under MSYS2. If PCL was built with SSE/AVX/MARCHNATIVE, then your own code should be, too. Ideally, you should check which flags are given to your compiler when compiling PCL vs when compiling your own code

A workaround you can also try is adding #define PCL_NO_PRECOMPILE before including the gp3.h header. Then, when building your own code, your compiler will disregard the GreedyProjectionTriangulation instantiation from the pcl_surface.dll and recompile the class from gp3.hpp (all flags and options will be consistent).

[edwardpier]

I tried your PCL_NO_PRECOMPILE workaround and it worked! I can't thank you enough for your fast and informative response. Some time in the future I will do the more careful job of sifting through the compiler optimization flags. But I think the fact that the workaround works is a strong indication that your assessment of the problem is correct. As far as I'm concerned you can close this ticket. Thank you!

[mvieth]

You are welcome!

[mvieth]

Minor follow-up: the thing about C++14 vs C++17 is very likely not the problem in your case. My best guess is that the problem appeared because you did not enable AVX while compiling your code (but it was enabled while building PCL).