Tool crashes after computing descriptors

[logiclrd]

I am trying to use the tool to automatically align two point clouds that have a lot of overlap. Unfortunately, I cannot release the point clouds for privacy reasons, but I can perform tests that may help to track down the source of the bug.

The command output looks like this:

Executing in parallel
Loaded point cloud with 240283 points:
Scan 3.ply
Loaded point cloud with 849421 points:
Scan 2.ply
Computed source cloud normals (240283)
Computed target cloud normals (849421)
Subsampled source cloud from 240283 -> 204804
Subsampled target cloud from 849421 -> 722911
Computed 204804 descriptors on source cloud keypoints
Segmentation fault (core dumped)

I ran the tool in GDB and got the following backtrace:

(gdb) bt
#0  __GI___libc_free (mem=0x9600d4) at malloc.c:3103
#1  0x00000000080698cb in boost::detail::sp_counted_impl_p<pcl::PointCloud<pcl::ReferenceFrame>>::dispose() ()
#2  0x000000000803c19a in boost::detail::sp_counted_base::release() ()
#3  0x000000000806cb67 in pcl::SHOTEstimationBase<pcl::PointXYZ, pcl::Normal, pcl::SHOT352, pcl::ReferenceFrame>::~SHOTEstimationBase() ()
#4  0x00000000080613d5 in Registrator::computeDescriptors() [clone ._omp_fn.4] ()
#5  0x00007ffff6c96c2e in ?? () from /usr/lib/x86_64-linux-gnu/libgomp.so.1
#6  0x00007ffffefd76db in start_thread (arg=0x7fffde150700) at pthread_create.c:463
#7  0x00007ffff678188f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
(gdb)

I am running this on Ubuntu LTS 18.04 on Windows 10. I am running VcXsrv in case the tool's --gui mode is trying to connect to an X server. The nature of the error makes me suspect that this is a logic error in the code, and not something specific to what platform it is running on.

What is my next step?

[logiclrd]

I can add that since this crash is occurring during the deletion of an object, I decided to see what would happen if I worked around it. I went to the Registrator class and made its allocation of pcl::SHOTEstimationBase<pcl::PointXYZ, pcl::Normal, pcl::SHOT352, pcl::ReferenceFrame> in computeDescriptors a heap allocation instead of a stack allocation. I allowed it to leak intentionally so that when computeDescriptors returns, it doesn't try to free it, avoiding the crash. I didn't have high hopes for this, because the crash suggests that something within the parent data structure is corrupt, and that corruption will probably affect things that follow as well. But, I fired it up anyway, and I got the following output:

Executing in parallel
Loaded point cloud with 240283 points:
Scan 3.ply
Loaded point cloud with 849421 points:
Scan 2.ply
Computed source cloud normals (240283)
Computed target cloud normals (849421)
Subsampled source cloud from 240283 -> 204804
Subsampled target cloud from 849421 -> 722911
Computed 204804 descriptors on source cloud keypoints
Computed 722911 descriptors on target cloud keypoints
Found 706607 correspondences
Retained 706607 correspondences after sample consensus filtering

At this point, the code then crashes with a SIGSEGV and the following backtrace:

(gdb) bt
#0  0x0000000008076933 in pcl::registration::TransformationEstimationSVD<pcl::PointXYZ, pcl::PointXYZ, float>::estimateRigidTransformation(pcl::ConstCloudIterator<pcl::PointXYZ>&, pcl::ConstCloudIterator<pcl::PointXYZ>&, Eigen::Matrix<float, 4, 4, 0, 4, 4>&) const ()
#1  0x0000000008076ad5 in pcl::registration::TransformationEstimationSVD<pcl::PointXYZ, pcl::PointXYZ, float>::estimateRigidTransformation(pcl::PointCloud<pcl::PointXYZ> const&, pcl::PointCloud<pcl::PointXYZ> const&, std::vector<pcl::Correspondence, Eigen::aligned_allocator<pcl::Correspondence> > const&, Eigen::Matrix<float, 4, 4, 0, 4, 4>&) const ()
#2  0x00000000080638cb in Registrator::computeCorrespondenceBasedTransformation() ()
#3  0x0000000008064461 in Registrator::correspondenceBasedRegistration() ()
#4  0x00000000080646a8 in Registrator::performRegistration(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >) ()
#5  0x0000000008035a75 in main ()
(gdb)

Does this get us any further??