skimage found an issue probably related to eigvalsh or generally threaded calls to linalg_umath.cpp.

Unfortunately, I have not yet narrowed it down further, and the test is slightly flaky (on my machine). For example, it seems to easier reproduce running the full file, rather than just the test.

To reproduce, I have to explicitly use NPY_BLAS_ORDER= (disable blas use), then run current main of skimage tests:

python3 -m pytest skimage/feature/tests/test_basic_features.py::test_multiscale_basic_features_deprecated_multichannel

I have a gdb traceback of a crash (the actual crash fluctuates a bit, so it may well be elsewhere):

#5  0x00007fffb7ef3f7f in release_evd<double> (params=0x7fffda26e940) at numpy/linalg/umath_linalg.cpp:1482
#6  eigh_wrapper<double> (JOBZ=<optimized out>, UPLO=<optimized out>, args=<optimized out>, dimensions=<optimized out>, 
    steps=<optimized out>) at numpy/linalg/umath_linalg.cpp:1555
#7  0x00007ffff639eed5 in generic_wrapped_legacy_loop (__NPY_UNUSED_TAGGEDcontext=<optimized out>, data=<optimized out>, 
    dimensions=<optimized out>, strides=<optimized out>, auxdata=0x7fffd19e9b30)
    at numpy/core/src/umath/legacy_array_method.c:87

So it seems eigvalsh and threading related. I need to dig further eventually, but maybe someone else has an idea what to look into (the umath code, the blas/lapack fallback code?).