Troubleshooting

Reporting issues

Things to report

We receive bug reports that are not actionable because impossible to reproduce. If you start a bug report, please make sure to include (use a gist if it is too bulky):

minimal code to reproduce the issue
a gdb stacktrace if C++ crash
please open a new issue unless you are certain that you have the exact same one as an existing one. This makes it easier for us to triage.
if GPU:
- version of OS, type of GPU, nvidia-smi output if GPU
- output of ldd on executable or _swigfaiss_gpu.so for the Python version

Also, please consider the following notes on how to productively report bugs.

Do not send e-mails for Faiss support (or call us on the phone (!)): we will redirect you to the issues page of Faiss. Do not send screen shots of text, copy-paste text instead.

Our issue workflow

We monitor issues actively. We label issues as:

question = you asked a question
help wanted = very basic question, maybe the community can help?
bug = we verified there is a bug
install = install-time problem (compile, etc.)
GPU = GPU-specific issue
cant-repro = we cannot repro because there is insufficient info or the bug does not appear when we test
enhancement = we will consider implementing a fix (not necessarily soon)

We expect users to close the issues they open. However, we aggressively close issues after 15 days of inactivity, even if they are not fixed. Feel free to re-open if you have the exact same problem.

Compile errors

undefined reference to `operator new[]`

Here you have probably erased the Faiss Makefile or forgotten to copy the makefile.inc as instructed in the INSTALL file.

What happens is that make is using a C compiler (cc) to compile C++.

Compile command without options

If you see

make
g++ -o tests/test_blas tests/test_blas.cpp

Then something happened with the Makefile. You may have overwritten it with makefile.inc for example.

SWIG error

cd ../python; swig -Doverride= -python -c++ -DGPU_WRAPPER -o ../python/swigfaiss_gpu_wrap.cxx ../swigfaiss.swig
../gpu/StandardGpuResources.h:67: Error: Syntax error in input(3).
make: *** [../python/swigfaiss_gpu_wrap.cxx] error 1

This is probably because the swig version is too old (swig 2.0 does not parse C++11 >>), and you may have erased the swig-generated files by doing make clean. You can restore them by

cd ../python
git checkout swigfaiss_gpu_wrap.cxx swigfaiss_gpu.py swigfaiss_wrap.cxx swigfaiss.py

Then make py again.

`NULL/nullptr/0`

C++ has changed several times how NULL pointers should be represented. In the C++ source, we use nullptr. This is recognized by C++11 compliant compilers. If your flavor of C++ has another idea about this, pass option -Dnullptr=NULL to the compiler.

Runtime errors

Missing module

ImportError: No module named swigfaiss

This means that Faiss was not compiled.

GPU Precomputed table error

If you get the following assertion error when constructing an GpuIndexIVFPQ with precomputed tables:

Faiss assertion usePrecomputed_ || IVFPQ::isSupportedNoPrecomputedSubDimSize( this->d / subQuantizers_) failed in void faiss::gpu::GpuIndexIVFPQ::assertSettings_() const at GpuIndexIVFPQ.cu:469Aborted (core dumped)

Then make sure that the ratio between the dimension and the PQ size (d/M) is one of the values mentioned in this function:

https://rawgit.com/facebookresearch/faiss/master/docs/html/PQScanMultiPassNoPrecomputed_8cu_source.html#l00029

If this is not the case, you can pre-process the input vectors with an OPQ transform.

Slow brute-force search with OpenBLAS

The search performance with OpenBLAS can degrade seriously because of a bad interaction between OpenMP and OpenBLAS threads. To avoid this, export OMP_WAIT_POLICY=PASSIVE before running the executable. See issue #53

Crashes in pure Python code

This has been fixed in version 1.4.0, that introduced automatic tracking of c++ references in Python. If you see this error in a version >=1.4.0, please report it as an issue.

No GPU Faiss

The most common symptom is:

AttributeError: module 'faiss' has no attribute 'StandardGpuResources'

because StandardGpuResources is the GPU-specific object that is most often accessed first.

The current behavior of Faiss is to try to load the GPU Faiss and fallback to CPU if that fails. This is irrespective of whether Faiss was compiled with GPU support or not. No error is reported in case of failure.

To actually see the error message, use

from faiss import _swigfaiss_gpu

which will output a more interpretable message like

ImportError: libcudart.so.9.2: cannot open shared object file: No such file or directory

Slow GPU intialization

The first time you access a Faiss GPU function may be very slow. This is due to the CUDA caching system that precompiles kernels and stores them to ~/.nv. If that directory is not writable or a dangling symlink or a very slow disk, then the slowness will happen every time Faiss is started, so it is useuful to make sure the directory is accessible.

Known GPU issues

For GPU faiss, add and search API calls need to be restructured somewhat to handle massive inputs in some cases, due to 32/64 bit integer confusion in various places. 32 bit integer math is much faster on the GPU, and this fact sadly leaked to the CPU side of GPU faiss. This is on the TODO list. Ideally, GPU faiss will handle any paging needed (so you can, say, pass a pointer to a 1 TB region of memory-mapped vectors to add or search and it would just work), but this requires some cleanup.
Excessive memory requests on the GPU do not produce friendly errors (e.g., attempting to enable precomputed codes on massive databases with a large number of coarse centroids, which may require 5+ GB of free storage). We will try to intercept this and make it friendlier in the future.

Deadlocking FAISS

It is possible to deadlock FAISS in Python / pybind11 interaction in the following scenario. Consider a simple pybind11 call from Python:

from faisstest_module import RunFaissTest

if __name__ == "__main__":
    RunFaissTest()

And the following C++ pybind11 module:

#include "faiss/Index.h"
#include "faiss/IndexIVFPQ.h"
#include "faiss/impl/io.h"
#include "faiss/index_factory.h"
#include "faiss/index_io.h"

void DoTest() {
  constexpr size_t numEmbeddings = 1048576;
  constexpr size_t embeddingDim = 256;

  std::vector<float> input(numEmbeddings * embeddingDim);

  std::unique_ptr<faiss::Index> index(faiss::index_factory(embeddingDim, "PQ32np"));

  index->train(numEmbeddings, input.data());

  std::cout << "Trained!" << std::endl;
}

PYBIND11_MODULE(faisstest_module, m) {
  m.def("RunFaissTest", []() {
    std::thread thr([] {
      // PyThreadState* state = PyEval_SaveThread();
      DoTest();
      // PyEval_RestoreThread(state);
    });
    thr.join();
  });
}

The python code will deadlock unless the commented rows are uncommented, such as

      PyThreadState* state = PyEval_SaveThread();
      DoTest();
      PyEval_RestoreThread(state);

The reason is that Python wrapper for FAISS installs a handler that checks whether Python wants to interrupt some computations. The handler interacts with GIL API. The handler is here https://github.com/facebookresearch/faiss/blob/main/faiss/python/swigfaiss.swig#L865 .