Skip to main content
`Ctrl`+`K`

# Debugging linear algebra related issues

Linear algebra related bug reports are among the most challenging issues to diagnose and address. This is not only because linear algebra can be challenging mathematically/algorithmically (that is true for many parts of SciPy), but because BLAS/LAPACK libraries are a complex build-time as well as runtime dependency - and we support a significant number of BLAS/LAPACK libraries.

This document aims to provide guidance about how to go about debugging linear algebra issues.

If there is a real bug, it can be in one of three places:

- In the BLAS library being used,

- In SciPy’s bindings for BLAS or LAPACK (generated by `numpy.f2py` and/or Cython),

- In SciPy’s algorithmic code.

A key first step is to determine whether the bug is in SciPy or in the BLAS library. To do so, the most efficient way to disambiguate the two is to set up your environment in such a way that you can achieve runtime switching between different BLAS libraries (something we don’t support out of the box, and isn’t possible with SciPy’s wheels from PyPI).

Upstream BLAS library authors strongly prefer to get clean reproducers (just like we do), which means: no Python involved. So this guide will also cover how to create reproducers in C or Fortran.

## Finding the BLAS library being used

SciPy has one function, `show_config`, to introspect the build configuration of an installed package. This allows querying for details of BLAS and LAPACK. E.g.:

    >>> blas_dep = scipy.show_config(mode='dicts')['Build Dependencies']['blas']
    >>> for key in blas_dep:
    ...     print(f"{key}:  {blas_dep[key]}")
    ...
    name:  openblas
    found:  True
    version:  0.3.23
    detection method:  pkgconfig
    include directory:  /home/user/miniforge/envs/scipy-dev/include
    lib directory:  /home/user/miniforge/envs/scipy-dev/lib
    openblas configuration:  USE_64BITINT=0 DYNAMIC_ARCH=1 DYNAMIC_OLDER= NO_CBLAS= NO_LAPACK=0 NO_LAPACKE= NO_AFFINITY=1 USE_OPENMP=0 PRESCOTT MAX_THREADS=128
    pc file directory:  /home/user/miniforge/envs/scipy-dev/lib/pkgconfig

This method will be correct for SciPy wheels and for local dev builds. It may be correct for other installs, however keep in mind that distros like conda-forge and Debian may be building against stub libraries (typically `blas.so`/`lapack.so`) and then installing another library for the user - in such cases, plain `blas` and `lapack` will be reported even if for example OpenBLAS or MKL is installed in the environment. For such installs, threadpoolctl will usually be able to report what the actual BLAS library in use is (except it doesn’t report on plain Netlib BLAS, see threadpoolctl#159):

    $ python -m threadpoolctl -i scipy.linalg
    [
      {
        "user_api": "blas",
        "internal_api": "openblas",
        "prefix": "libopenblas",
        "filepath": "/home/user/miniforge/envs/dev/lib/libopenblasp-r0.3.21.so",
        "version": "0.3.21",
        "threading_layer": "pthreads",
        "architecture": "SkylakeX",
        "num_threads": 24
      }
    ]

Other ways of introspecting that can be helpful in local dev environments include:

1. Checking dependencies of shared libraries:

Linux

    $ ldd build/scipy/linalg/_fblas.cpython-*.so
    ...
    libopenblas.so.0 => /home/user/miniforge/envs/scipy-dev/lib/libopenblas.so.0 (0x0000780d6d000000)

macOS

    % otool -L build/scipy/linalg/_fblas.cpython-310-darwin.so
    build/scipy/linalg/_fblas.*.so:
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1336.61.1)
        @rpath/libopenblas.0.dylib (compatibility version 0.0.0, current version 0.0.0)

2. Checking whether the linked library contains a given symbol. E.g., conda-forge installs a `libblas.so` that may be any supported library:

Linux

    $ nm -gD ~/miniforge/envs/scipy-dev/lib/libblas.so | rg openblas_set_num_threads
    0000000000362990 T openblas_set_num_threads

macOS

    % nm ~/miniforge/envs/scipy-dev/lib/libblas.3.dylib | rg openblas_set_num_threads
    000000000015b6b0 T _openblas_set_num_threads

## Setting up your environment for switching BLAS libraries

We’ll cover several ways of switching between different BLAS libraries, because the easiest method may depend on your OS/distro and on whether you want a released version of SciPy or a development build.

### Conda-forge

Perhaps the easiest way is to use the runtime switching abilities provided by distros. For example, to create a conda environment with the latest SciPy release installed and then switching between OpenBLAS, Netlib BLAS/LAPACK, and MKL is as simple as:

    $ conda create -n blas-switch scipy threadpoolctl
    $ conda activate blas-switch
    $ python -m threadpoolctl -i scipy.linalg
    ...
        "user_api": "blas",
        "internal_api": "openblas",

    $ conda install "libblas=*=*netlib"
    ...
      libblas                         3.9.0-21_linux64_openblas --> 3.9.0-5_h92ddd45_netlib
      libcblas                        3.9.0-21_linux64_openblas --> 3.9.0-5_h92ddd45_netlib
      liblapack                       3.9.0-21_linux64_openblas --> 3.9.0-5_h92ddd45_netlib

    $ conda install "libblas=*=*mkl"
    ...
      libblas                           3.9.0-5_h92ddd45_netlib --> 3.9.0-21_linux64_mkl
      libcblas                          3.9.0-5_h92ddd45_netlib --> 3.9.0-21_linux64_mkl
      liblapack                         3.9.0-5_h92ddd45_netlib --> 3.9.0-21_linux64_mkl

    $ python -m threadpoolctl -i scipy.linalg
    ...
      "user_api": "blas",
      "internal_api": "mkl",

This can be done for development builds as well, when building via `spin` in the exact same way as in SciPy’s conda-forge build recipe (outputs omitted for brevity, they’re similar to the ones above):

    $ conda env create -f environment.yml
    $ conda activate scipy-dev
    $ conda install "libblas=*=*netlib"  # necessary, we need to build against blas/lapack
    $ spin build -S-Dblas=blas -S-Dlapack=lapack -S-Duse-g77-abi=true
    $ spin test -s linalg  # run tests to verify
    $ conda install "libblas=*=*mkl"
    $ spin test -s linalg
    $ conda install "libblas=*=*openblas"

### Linux distro package managers

A number of Linux distros use the `update-alternatives` mechanism to allow switching between different BLAS libraries via the system package manager. Note that this is a generic mechanism to manage “multiple implementations of the same library or tool” situations, rather than something specific to BLAS/LAPACK. It’s similar to the conda-forge method above, in that it works for distro-provided `scipy` packages as well as for development builds against the reference `libblas`/`liblapack` interfaces.

The interface looks like:

    $ update-alternatives --config libblas.so.3
    $ update-alternatives --config liblapack.so.3

which will open a menu in the terminal with all available libraries to choose from. Because the interface and available options are likely to vary across distros, we link here to the Debian documentation for BLAS/LAPACK switching and avoid documenting in more detail how this works on other distros.

Note that Fedora is an exception; it is the only distro that ships FlexiBLAS (see the next section for more on that) and allows installing multiple BLAS libraries in parallel so true runtime switching without having to invoke the system package manager becomes possible. See the Fedora docs on system-level and user-level selection for more details.

### FlexiBLAS

FlexiBLAS provides runtime switching support (among other things) for all installed BLAS libraries that it can detect. There are a few limitations at the time of writing (March 2024), primarily: no support for Windows, no support for macOS Accelerate (the updated version, with `NEWLAPACK` symbols). If those limitations don’t matter for you, FlexiBLAS can be a quite useful tool for efficient debugging, including for versions of OpenBLAS and other BLAS libraries that you have to build from source.

Once you have everything set up, the development experience is:

    $ spin build -S-Dblas=flexiblas -S-Dlapack=flexiblas
    $ FLEXIBLAS=NETLIB spin test -s linalg
    $ FLEXIBLAS=OpenBLAS spin test -s linalg
    # Or export the environment variable to make the selection stick:
    $ export FLEXIBLAS=OpenBLAS

You can also provide a path to a built BLAS library (e.g., `FLEXIBLAS="libbhlas_atlas.so"`) - see the usage docs in its README for more details.

Unless you’re on Fedora, you will likely have to build FlexiBLAS from source, which is a bit of work. The good news is that this should work no matter if you’re on Linux or macOS, and use Python via virtualenvs, conda environments, or in some other way. We’ll go through how to build OpenBLAS and FlexiBLAS from source, to allow debugging whether something in the latest OpenBLAS version is different from Netlib BLAS/LAPACK (or MKL) or not.

The below should work in any environment where you can build SciPy itself; the only additional tool we need is CMake (install with, for example, `pip install cmake`).

Clone each repository:

    $ cd ..  # starting from the root of the local `scipy` repo
    $ mkdir flexiblas-setup && cd flexiblas-setup
    $ git clone https://github.com/OpenMathLib/OpenBLAS.git openblas
    $ git clone https://github.com/mpimd-csc/flexiblas.git
    $ mkdir built-libs  # our local prefix to install everything to

Build OpenBLAS:

    $ cd openblas
    $ mkdir build && cd build
    $ cmake .. -DBUILD_SHARED_LIBS=ON -DCMAKE_INSTALL_PREFIX=$PWD/../../built-libs
    $ cmake --build . -j
    $ cmake --install . --prefix $PWD/../../built-libs
    $ cd ../..

Build FlexiBLAS:

    $ cd flexiblas
    $ mkdir build && cd build
    $ # Note: this will also pick up the libraries in your system/env libdir
    $ cmake .. -DEXTRA="OpenBLAS" -DLAPACK_API_VERSION=3.9.0 \
        -DOpenBLAS_LIBRARY=$PWD/../../built-libs/lib/libopenblas.so \
        -DCMAKE_INSTALL_PREFIX=$PWD/../../built-libs
    $ cmake --build . -j
    $ cmake --install . --prefix $PWD/../../built-libs
    $ cd ../..

We’re now ready to build SciPy against FlexiBLAS:

    $ export PKG_CONFIG_PATH=$PWD/flexiblas-setup/built-libs/lib/pkgconfig/
    $ cd scipy
    $ spin build -S-Dblas=flexiblas -S-Dlapack=flexiblas
    ...
    Run-time dependency flexiblas found: YES 3.4.2

Now we can run the tests. Note that the `NETLIB` option is built without having to specify it; it’s the default in FlexiBLAS and sources are included in its repository:

    $ FLEXIBLAS=OpenBLAS spin test -s linalg
    $ FLEXIBLAS=NETLIB spin test -s linalg
    $ spin test -s linalg  # uses the default (NETLIB)

This backend switching can also be done inside a Python interpreter with `threadpoolctl` (see its README for details).

Other libraries available on the system can be inspected with:

    $ ./flexiblas-setup/built-libs/bin/flexiblas list

Note

Using local builds of reference BLAS/LAPACK or BLIS is more difficult, because FlexiBLAS requires a single shared library which contains all needed symbols. It may be feasible to use a separate `libblas` and `liblapack` as the “system library”, but this has proven to be more fragile and difficult to build (so this is YMMV). In case you do want to try:

Build reference BLAS and LAPACK:

> $ git clone Reference-LAPACK/lapack.git $ cd lapack $ mkdir build && cd build $ cmake -DCBLAS=ON -DBUILD_SHARED_LIBS=OFF .. $ cmake –build . -j $ cmake –install . –prefix $PWD/../../built-libs

Then add the following two lines to the `cmake ..` configure command for FlexiBLAS:

    -DSYS_BLAS_LIBRARY=$PWD/../../built-libs/lib/libblas.a \
    -DSYS_LAPACK_LIBRARY=$PWD/../../built-libs/lib/liblapack.a \

## Creating reproducers in C or Fortran

Our experience tells us that a large majority of bugs are inside SciPy rather than in OpenBLAS or another BLAS library. If the testing with different BLAS libraries tells us though that the problem is specific to a single BLAS library (maybe even a single version of that library with a regression), the next step is to produce a reproducer in C or Fortran; doing so is necessary for reporting the bug upstream, and makes it much easier for the BLAS library developers to address the problem.

To get from a Python reproducer which uses a `scipy` function with NumPy arrays as input to a C/Fortran reproducer, it is necessary to find the code path taken in SciPy and determine which exact BLAS or LAPACK function is called, and with what inputs (note: the answer may be contained in the `.pyf.src` f2py signature files; looking into the generated `_flapackmodule.c` in the build directory may be useful too). This can then be reproduced in C/Fortran by defining some integer/float variables and arrays (typically small arrays with hardcoded numbers are enough).

Argument lists of BLAS and LAPACK functions can be looked up in for example the Netlib LAPACK docs or the Reference-LAPACK/lapack repository.

Below a reproducer is shown for an issue in reference LAPACK, which was reported as a SciPy issue in scipy#11577. We’ll name the file `ggev_repro_gh_11577.c|f90`:

C

    #include <stdio.h>
    #include "lapacke.h"

    #define n 4

    int main()
    {
        int lda=n, ldb=n, ldvr=n, ldvl=n, info;
        char jobvl='V', jobvr='V';
        double alphar[n], alphai[n], beta[n];

        double vl[n*n], vr[n*n];
        // int lwork = 156;
        // double work[156];    /* cheat: 156 is the optimal lwork from the actual lapack call*/

        double a[n*n] = {12.0, 28.0, 76.0, 220.0,
                         16.0, 32.0, 80.0, 224.0,
                         24.0, 40.0, 88.0, 232.0,
                         40.0, 56.0, 104.0, 248.0};

        double b[n*n] = {2.0, 4.0, 10.0, 28.0,
                         3.0, 5.0, 11.0, 29.0,
                         5.0, 7.0, 13.0, 31.0,
                         9.0, 11.0, 17.0, 35.0};

        info = LAPACKE_dggev(LAPACK_ROW_MAJOR, jobvl, jobvr, n, a, lda, b,
                             ldb, alphar, alphai, beta, vl, ldvl, vr, ldvr); //, work, lwork, info);

        printf("info = %d\n", info);

        printf("Re(eigv) = ");
        for(int i=0; i < n; i++){
            printf("%f , ", alphar[i] / beta[i] );
        }
        printf("\nIm(eigv = ");
        for(int i=0; i < n; i++){
            printf("%f , ", alphai[i] / beta[i] );
        }
        printf("\n");
    }

Fortran

    !A = numpy.array([[12.0, 28.0, 76.0, 220.0], [16.0, 32.0, 80.0, 224.0], [24.0, 40.0, 88.0, 232.0], [40.0, 56.0, 104.0, 248.0]], dtype='float64')
    ! B = numpy.array([[2.0, 4.0, 10.0, 28.0], [3.0, 5.0, 11.0, 29.0], [5.0, 7.0, 13.0, 31.0], [9.0, 11.0, 17.0, 35.0]], dtype='float64')
    ! D, V = scipy.linalg.eig(A, B); D
    implicit none
    integer, parameter :: n = 4

    integer :: lda, ldb, ldvr, ldvl, lwork, info
    character*1 :: jobvl, jobvr
    real*8 :: alphar(n)
    real*8 :: alphai(n)
    real*8 :: beta(n)
    real*8 :: vl(n, n)
    real*8 :: vr(n, n)
    real*8, allocatable :: work(:)

    real*8 :: a(n, n)
    real*8 :: b(n, n)

    a(1, :) = (/12.0, 28.0, 76.0, 220.0/)
    a(2, :) = (/16.0, 32.0, 80.0, 224.0/)
    a(3, :) = (/24.0, 40.0, 88.0, 232.0/)
    a(4, :) = (/40.0, 56.0, 104.0, 248.0/)

    b(1, :) = (/2.0, 4.0, 10.0, 28.0/)
    b(2, :) = (/3.0, 5.0, 11.0, 29.0/)
    b(3, :) = (/5.0, 7.0, 13.0, 31.0/)
    b(4, :) = (/9.0, 11.0, 17.0, 35.0/)

    lda = n
    ldb = n
    ldvr = n
    ldvl = n
    jobvr = 'V'
    jobvl = 'V'

    ! workspace query

    allocate(work(1:8*n)) ! min value
    lwork = -1

    print*, 'workspace query: lwork = ', lwork

    call dggev(jobvl, jobvr, n, a, lda, b, ldb, alphar, alphai, beta, vl, ldvl, vr, ldvr, work, lwork, info)

    print*, 'info = ', info
    lwork = int(work(1))
    print*, 'opt lwork =', lwork

    ! do the work

    deallocate(work)
    allocate(work(1:lwork))

    call dggev(jobvl, jobvr, n, a, lda, b, ldb, alphar, alphai, beta, vl, ldvl, vr, ldvr, work, lwork, info)

    print*
    print*, 'info = ', info
    print*, 'alphar = ', alphar
    print*, 'alphai = ', alphai
    print*, 'beta = ', beta
    print*
    print*, 'Re(eigv) = ', alphar / beta
    print*, 'Im(eigv) = ', alphai / beta

    deallocate(work)
    end

Now we need to compile this reproducer locally and run it. If we’re invoking a compiler directly, we need to add the needed compile and link flags by hand. The include path will depend on your local install, and the link flags will depend on which library you’re testing. For example, to test against a local build of OpenBLAS:

C

    $ gcc ggev_repro_gh_11577.c \
      -I$PWD/../flexiblas-setup/built-libs/include/ \
      -L$PWD/../flexiblas-setup/built-libs/lib -lopenblas
    $ ./a.out  # to run the reproducer

Fortran

    $ gfortran ggev_repro_gh_11577.f90 \
      -I/$PWD/../flexiblas-setup/built-libs/include/ \
      -L$PWD/../flexiblas-setup/built-libs/lib -lopenblas
    $ ./a.out  # to run the reproducer

For reference BLAS/LAPACK, the `-lopenblas` should be replaced with `-lblas -llapack`.

Note that the explicit paths are only needed for libraries in non-standard locations (like the ones we built in this guide). For building against a package manager-installed library for which the shared library and headers are on the normal compiler search path (e.g., in `/usr/lib` and `/usr/include`, or inside a conda env when using compilers from the same env), they can be left out:

C

    $ gcc ggev_repro_gh_11577.c -lopenblas
    $ ./a.out  # to run the reproducer

Fortran

    $ gfortran ggev_repro_gh_11577.f90 -lopenblas
    $ ./a.out  # to run the reproducer

Alternatively (and probably a more robust way), use a small `meson.build` file to automate this and avoid the manual paths:

C

    project('repro_gh_11577', 'c')

    openblas_dep = dependency('openblas')

    executable('repro_c',
        'ggev_repro_gh_11577.c',
        dependencies: openblas_dep
    )

To then build the test and run it:

    $ export PKG_CONFIG_PATH=~/code/tmp/flexiblas-setup/built-libs/lib/pkgconfig/
    $ meson setup build
    $ ninja -C build
    $ ./build/repro_c  # output may vary

    info = 0
    Re(eigv) = 4.000000 , 8.000000 , inf , -inf ,
    Im(eigv = 0.000000 , 0.000000 , -nan , -nan ,

Fortran

    project('repro_gh_11577', 'fortran')

    openblas_dep = dependency('openblas')

    executable('repro_f90',
        'ggev_repro_gh_11577.f90',
        dependencies: openblas_dep
    )

To then build the test and run it:

    $ export PKG_CONFIG_PATH=~/code/tmp/flexiblas-setup/built-libs/lib/pkgconfig/
    $ meson setup build
    $ ninja -C build
    $ ./build/repro_f90  # output may vary

    workspace query: lwork =           -1
    info =            0
    opt lwork =         156

    info =            0
    alphar =    1.0204501477442456        11.707793036240817        3.7423579363517347E-014  -1.1492523608519701E-014
    alphai =    0.0000000000000000        0.0000000000000000        0.0000000000000000        0.0000000000000000
    beta =   0.25511253693606051        1.4634741295300704        0.0000000000000000        0.0000000000000000

    Re(eigv) =    4.0000000000000142        8.0000000000001741                       Infinity                 -Infinity
    Im(eigv) =    0.0000000000000000        0.0000000000000000                            NaN                       NaN

Warning

When you have multiple versions/builds of the same BLAS library on your machine, it’s easy to accidentally pick up the wrong one during the build (remember: `-lopenblas` only says “link against some `libopenblas.so`). If you’re not sure, use `ldd` on the test executable you built to inspect which shared library it’s linked against.

## Debugging linalg issues with `gdb`

When debugging linalg issues, it is sometimes useful to step through both Python and C code. You can use `pdb` for the former, and `gdb` for the latter.

First, prepare a small python reproducer, with a breakpoint. For example:

    $ cat chol.py
    import numpy as np
    from scipy import linalg
    n = 40
    rng = np.random.default_rng(1234)
    x = rng.uniform(size=n)
    a = x[:, None] @ x[None, :] + np.identity(n)

    breakpoint()      # note a breakpoint
    linalg.cholesky(a)

Then, you will need to run it under the `gdb` and add a C-level breakpoint at the LAPACK function. This way, your execution will stop twice: first on the Python breakpoint and then on the C breakpoint, and you will be able to step through and inspect values of both Python and C variables.

To find out the LAPACK name, read the python source of the SciPy function and use `nm` on the `.so` library to find out the exact name. For the Cholesky factorization above, the LAPACK function is `?potrf`, and the C name on Ubuntu linux is `dpotrf_` (it may be spelled with or without the trailing underscore, in uppper case or lower case, depending on the system).

Here is an example `gdb` session:

    $ gdb --args python chol.py
    ...
    (gdb) b dpotrf_     # this adds a C breakpoint (type "y" below)
    Function "dpotrf_" not defined.
    Make breakpoint pending on future shared library load? (y or [n]) y
    Breakpoint 1 (dpotrf_) pending.
    (gdb) run    # run the python script
    ...
    > /home/br/temp/chol/chol.py(12)<module>()
    -> linalg.cholesky(a)   # execution stopped at the python breakpoint
    (Pdb) p a.shape  # ... inspect the python state here
    (40, 40)
    (Pdb) c     # continue execution until the C breakpoint

    Thread 1 "python" hit Breakpoint 1, 0x00007ffff4c48820 in dpotrf_ ()
       from /home/br/miniforge/envs/scipy-dev/lib/python3.10/site-packages/numpy/core/../../../../libcblas.so.3
    (gdb) s     # step through the C function
    Single stepping until exit from function dpotrf_,
    which has no line number information.
    f2py_rout__flapack_dpotrf (capi_self=<optimized out>, capi_args=<optimized out>,
        capi_keywds=<optimized out>, f2py_func=0x7ffff4c48820 <dpotrf_>)
        at scipy/linalg/_flapackmodule.c:63281
    ....
    (gdb) p lda    # inspect values of C variables
    $1 = 40

    # print out the C backtrace
    (gdb) bt
    #0  0x00007ffff3056b1e in f2py_rout.flapack_dpotrf ()
       from /path/to/site-packages/scipy/linalg/_flapack.cpython-311-x86_64-linux-gnu.so
    #1  0x0000555555734323 in _PyObject_MakeTpCall (tstate=0x555555ad0558 <_PyRuntime+166328>,
        callable=<fortran at remote 0x7ffff40ffc00>, args=<optimized out>, nargs=1,
        keywords=('lower', 'overwrite_a', 'clean'))
        at /usr/local/src/conda/python-3.11.8/Objects/call.c:214
    ...

Depending on your system, you may need to build SciPy with debug build type, and unset CFLAGS/CXXFLAGS environment variables. See the NumPy debugging guide for more details.