Troubleshooting

Reporting bugs

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.

Python errors

ImportError: No module named swigfaiss

This means that Faiss was not compiled.

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.

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.

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.

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

Known 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.