Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Double free or corruption error in greedy_projection #1889

Closed
zachbogorad opened this issue Jun 15, 2017 · 2 comments
Closed

Double free or corruption error in greedy_projection #1889

zachbogorad opened this issue Jun 15, 2017 · 2 comments

Comments

@zachbogorad
Copy link

Environment

  • Operating System and version: Ubuntu 16.04
  • Compiler: gcc 5.4.0
  • PCL Version: 1.8.0
  • Eigen Version: 3.3

Expected Behavior

I'm trying to get the greedy_projection example provided and described here to work. I'm running it on the example input file listed there ("bun0.pcd"). I'm not actually sure what the output for that should look like, but at the moment I get no output anyway so it doesn't matter.

Current Behavior

Everything compiles fine as far as I can tell, but when I try to run the binary, I get a double free or corruption error. A gdb backtrace gives:

#0 0x00007fffda06c428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54
#1 0x00007fffda06e02a in __GI_abort () at abort.c:89
#2 0x00007fffda0ae7ea in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7fffda1c72e0 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175
#3 0x00007fffda0b6e0a in malloc_printerr (ar_ptr=, ptr=, str=0x7fffda1c73f0 "double free or corruption (out)", action=3) at malloc.c:5004
#4 _int_free (av=, p=, have_lock=0) at malloc.c:3865
#5 0x00007fffda0ba98c in __GI___libc_free (mem=) at malloc.c:2966
#6 0x0000000000442d71 in Eigen::internal::aligned_free (ptr=0x6dcb80) at /usr/include/eigen3/Eigen/src/Core/util/Memory.h:247
#7 0x000000000045139c in Eigen::aligned_allocator<Eigen::Matrix<float, 3, 1, 0, 3, 1> >::deallocate (this=0x7fffffffd8a8, p=0x6dcb80) at /usr/include/eigen3/Eigen/src/Core/util/Memory.h:824
#8 0x000000000044fa54 in std::allocator_traits<Eigen::aligned_allocator<Eigen::Matrix<float, 3, 1, 0, 3, 1> > >::deallocate (__a=..., __p=0x6dcb80, __n=397) at /usr/include/c++/5/bits/alloc_traits.h:386
#9 0x000000000044dd2a 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=0x7fffffffd8a8, __p=0x6dcb80,
__n=397) at /usr/include/c++/5/bits/stl_vector.h:178
#10 0x000000000044b6f0 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=0x7fffffffd8a8,
__in_chrg=) at /usr/include/c++/5/bits/stl_vector.h:160
#11 0x00000000004487db in std::vector<Eigen::Matrix<float, 3, 1, 0, 3, 1>, Eigen::aligned_allocator<Eigen::Matrix<float, 3, 1, 0, 3, 1> > >::~vector (this=0x7fffffffd8a8, __in_chrg=)
at /usr/include/c++/5/bits/stl_vector.h:425
#12 0x0000000000457658 in pcl::GreedyProjectionTriangulationpcl::PointNormal::~GreedyProjectionTriangulation (this=0x7fffffffd810, __in_chrg=)
at /usr/local/include/pcl-1.8/pcl/surface/gp3.h:138
#13 0x000000000044222d in main (argc=1, argv=0x7fffffffdaf8) at /home/zach/Work/kasper/KEMField/Source/2.0/Applications/greedy_projection.cpp:38

I know the example has worked for at least one colleague and I'm not sure what the difference is that's causing it not to work for me. I'll be happy to provide other details about my installation, I just don't know what else is needed.

@SergioRAgostinho
Copy link
Member

Sorry for the late reply. I have the impression that your problem might be closely related to #2013, and the reason behind it is #2013 (comment). Can you apply the following patch #2100 and report the results?

Basically you just need to make sure that the same SSE flags that were used to compile PCL are being used to compile the application which is linking against PCL.

@SergioRAgostinho
Copy link
Member

This one is probably fixed now. Closing.

@SergioRAgostinho SergioRAgostinho removed the needs: author reply Specify why not closed/merged yet label Dec 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants