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

__memmove_avx_unaligned segfault #279

Closed
luisremis opened this issue Dec 12, 2017 · 7 comments
Closed

__memmove_avx_unaligned segfault #279

luisremis opened this issue Dec 12, 2017 · 7 comments

Comments

@luisremis
Copy link

Thread 71 "main" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff4be2d700 (LWP 87175)]
__memmove_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:238
238 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory.
(gdb) bt
#0 __memmove_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:238
#1 0x00007fffeffd17fe in std::__copy_move<false, true, std::random_access_iterator_tag>::__copy_m (__result=, __last=, __first=) at /usr/include/c++/5/bits/stl_algobase.h:384
#2 std::__copy_move_a<false, float const*, float*> (__result=, __last=, __first=) at /usr/include/c++/5/bits/stl_algobase.h:402
#3 std::__copy_move_a2<false, float const*, float*> (__result=0x7ffe05ccb010, __last=, __first=) at /usr/include/c++/5/bits/stl_algobase.h:440
#4 std::copy<float const*, float*> (__result=0x7ffe05ccb010, __last=, __first=) at /usr/include/c++/5/bits/stl_algobase.h:472
#5 std::__uninitialized_copy::__uninit_copy<float const*, float*> (__result=0x7ffe05ccb010, __last=, __first=) at /usr/include/c++/5/bits/stl_uninitialized.h:93
#6 std::uninitialized_copy<float const*, float*> (__result=0x7ffe05ccb010, __last=, __first=) at /usr/include/c++/5/bits/stl_uninitialized.h:126
#7 std::__uninitialized_copy_a<float const*, float*, float> (__result=0x7ffe05ccb010, __last=, __first=) at /usr/include/c++/5/bits/stl_uninitialized.h:281
#8 std::vector<float, std::allocator >::_M_range_insert<float const*> (__last=, __first=, __position=1, this=0x7ffdcc002660) at /usr/include/c++/5/bits/vector.tcc:643
#9 std::vector<float, std::allocator >::_M_insert_dispatch<float const*> (__last=, __first=, __pos=..., this=0x7ffdcc002660) at /usr/include/c++/5/bits/stl_vector.h:1377
#10 std::vector<float, std::allocator >::insert<float const*, void> (__last=, __first=, __position=1, this=0x7ffdcc002660) at /usr/include/c++/5/bits/stl_vector.h:1099
#11 faiss::IndexFlat::add (this=0x7ffdcc002640, n=128, x=) at IndexFlat.cpp:31

I get this error (gdb backtrace) when dealing with small vectors (128 dimensions). I tried using and removing -mavx flag.

Have you encountered this error before? Any clue?

@mdouze
Copy link
Contributor

mdouze commented Dec 15, 2017

Hi
This looks like a generic memory corruption. Are you sure that the data pointer you provide on input is large enough?

@luisremis
Copy link
Author

Fixed after some code refactoring, indeed, the problem was most likely somewhere else. If I face the problem again, I will try to reproduce it. Thanks for your reply.

@mahmoodn
Copy link

mahmoodn commented Jul 8, 2021

@luisremis How did you fix that for small vectors?

@luisremis
Copy link
Author

the issue, if I recall correctly, was not related to the vectors sizes, it was something else wrong in my application.

@santiweide
Copy link

curious about how you solved it...have met the same core

@itwujian
Copy link

me too

@shan-weiqiang
Copy link

Do you use std::vector in a multi thread situation? If yes there might be a memeory relocation problem, say: one thread insert a value, causing the vector to enlarge it's size and relocate all it's elements in another memory range. However, another thread stll owns some ref(pointer) to the original memory range of this vector, this might cause the seg fault.

if you reserve the std::vector first and the problem is gone, big chances that this is the reason behind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants