Control: forwarded -1 https://github.com/facebookresearch/faiss/issues/5294 Control: severity -1 important
On Fri, Aug 07, 2026 at 10:22:30PM +0200, Aurelien Jarno wrote: >... > On 2026-08-06 17:28, Paul Gevers wrote: > > Source: faiss > > Version: 1.13.2-1 > > Severity: serious > > X-Debbugs-CC: [email protected] [email protected] > > Tags: sid forky > > User: [email protected] > > Usertags: needs-update > > Control: affects -1 src:gcc-defaults > > User: [email protected] > > Usertags: riscv64 >... > > 7572s test 119 > > 7572s Start 119: HNSWTest.TEST_search_from_candidate_unbounded > > 7572s 7572s 119: Test command: > > /tmp/autopkgtest.Eu4j7u/autopkgtest_tmp/tests/build/faiss_test > > "--gtest_filter=HNSWTest.TEST_search_from_candidate_unbounded" > > "--gtest_also_run_disabled_tests" > > 7572s 119: Working Directory: > > /tmp/autopkgtest.Eu4j7u/autopkgtest_tmp/tests/build > > 7572s 119: Test timeout computed to be: 10000000 > > 7572s 119: WARNING clustering 1000 points to 40 centroids: please provide at > > least 1560 training points > > 7572s 119: Running main() from ./googletest/src/gtest_main.cc > > 7572s 119: Note: Google Test filter = > > HNSWTest.TEST_search_from_candidate_unbounded > > 7572s 119: [==========] Running 1 test from 1 test suite. > > 7572s 119: [----------] Global test environment set-up. > > 7572s 119: [----------] 1 test from HNSWTest > > 7572s 119: [ RUN ] HNSWTest.TEST_search_from_candidate_unbounded > > 7572s 119/133 Test #119: HNSWTest.TEST_search_from_candidate_unbounded > > .....................***Exception: SegFault 0.14 sec > > > > > > 7577s 7577s 99% tests passed, 1 tests failed out of 133 > > 7577s 7577s Total Test time (real) = 444.00 sec > > 7577s 7577s The following tests FAILED: > > 7577s 119 - HNSWTest.TEST_search_from_candidate_unbounded (SEGFAULT) > > 7577s Errors while running CTest > > While the test seemed to fail reliably on the debci host, I wasn't able > to reproduce the problem. After giving it back, it succeeded [1] with > gcc-16, so it's not a regression, but rather an unreliable test. > > I also noticed that the autopkgtest time varies quite a lot (up to a > factor 3 for a given debci runner), so I guess the high level of > concurrent autopkgtests job following the gcc-default upload explains > that. > > I have therefore tried to reproduce the issue under high load, and I > have been successful. Here is the corresponding backtrace: >... > | Program terminated with signal SIGSEGV, Segmentation fault. > | #0 0x0000002ad7aeb6c2 in faiss::fvec_L2sqr_batch_4(float const*, float > const*, float const*, float const*, float const*, unsigned long, float&, > float&, float&, float&) () > | [Current thread is 1 (Thread 0x3faf4420e0 (LWP 16849))] > | (gdb) bt > | #0 0x0000002ad7aeb6c2 in faiss::fvec_L2sqr_batch_4(float const*, float > const*, float const*, float const*, float const*, unsigned long, float&, > float&, float&, float&) () > | #1 0x0000002ad7823f0c in faiss::(anonymous > namespace)::FlatL2Dis::distances_batch_4(long, long, long, long, float&, > float&, float&, float&) () > | #2 0x0000002ad79014f6 in faiss::search_neighbors_to_add(faiss::HNSW&, > faiss::DistanceComputer&, std::priority_queue<faiss::HNSW::NodeDistCloser, > std::vector<faiss::HNSW::NodeDistCloser, > std::allocator<faiss::HNSW::NodeDistCloser> >, std:: > | less<faiss::HNSW::NodeDistCloser> >&, int, float, int, > faiss::VisitedTable&, bool) () > | #3 0x0000002ad7902f94 in > faiss::HNSW::add_links_starting_from(faiss::DistanceComputer&, int, int, > float, int, omp_lock_t*, faiss::VisitedTable&, bool) () > | #4 0x0000002ad79033d2 in > faiss::HNSW::add_with_locks(faiss::DistanceComputer&, int, int, > std::vector<omp_lock_t, std::allocator<omp_lock_t> >&, faiss::VisitedTable&, > bool) () > | #5 0x0000002ad78498b0 in faiss::(anonymous > namespace)::hnsw_add_vertices(faiss::IndexHNSW&, unsigned long, unsigned > long, float const*, bool, bool) [clone ._omp_fn.0] () > | #6 0x0000003fafeeff3e in ?? () from /usr/lib/riscv64-linux-gnu/libgomp.so.1 > | #7 0x0000003faf64e330 in ?? () from /usr/lib/riscv64-linux-gnu/libc.so.6 > | #8 0x0000003faf69b670 in ?? () from /usr/lib/riscv64-linux-gnu/libc.so.6 >... > At this stage, I haven't debugged it further. I'll try to see if I can > reproduce the issue on another architecture. Given it's not a > regression, I guess the severity can be decreased. There is an upstream issue with the same backtrace on MacOS, I'm marking the bug as forwarded to that. The reproducer from the upstream issue does not reproduce for me in current unstable (on riscv64 and amd64). > Regards > Aurelien >... cu Adrian
