BUG: `linalg.inv` crashing on windows arm64

[rgommers]

Describe the issue:

The linalg.inv function is showing consistent crashes with the numpy 2.3.1 and 2.3.2 wheels for win_arm64 (Windows on Arm, WoA) installed from PyPI with Windows fatal exception: access violation.

The traceback in SciPy CI points at this line:

numpy/numpy/linalg/_linalg.py

Line 669 in c6b5258

ainv = _umath_linalg.inv(a, signature=signature)

Reproduce the code example:

Here is a reproducer:


@pytest.mark.parametrize('dtype', [np.complex64, np.complex128])
@pytest.mark.parametrize('mtype', ['symm', 'herm'])  # matrix type
def test_numpy_inv_crash_win_arm64(dtype, mtype):
    rng = np.random.default_rng(1723059677121834)
    n = 20
    A = rng.random((n, n)) + rng.random((n, n))*1j
    if np.issubdtype(dtype, np.floating):
        A = A.real
    A = A.astype(dtype)
    A = A + A.T if mtype == 'symm' else A + A.conj().T
    ref = np.linalg.inv(A)


It's crashing for all combinations of `complex64`/`complex128` and symmetric/hermitian matrices. `float32`/`float64` dtypes are working fine.

Error message:

This ran in SciPy CI with `pytest-xdist` with 2 workers.

Windows fatal exception: access violation
...

 Current thread 0x00001f34 (most recent call first):
  File "C:\hostedtoolcache\windows\Python\3.12.10\arm64\Lib\site-packages\numpy\linalg\_linalg.py", line 669 in inv
  File "C:\a\scipy\scipy\build-install\Lib\site-packages\scipy\linalg\tests\test_lapack.py", line 3527 in test_numpy_inv_crash_win_arm64
  File "C:\hostedtoolcache\windows\Python\3.12.10\arm64\Lib\site-packages\_pytest\python.py", line 157 in pytest_pyfunc_call
  File "C:\hostedtoolcache\windows\Python\3.12.10\arm64\Lib\site-packages\pluggy\_callers.py", line 121 in _multicall
...

Python and NumPy Versions:

Python 3.11/3.12
NumPy 2.3.1/2.3.2

Runtime Environment:

(can't easily provide this, I don't have local hardware)

Context for the issue:

The SciPy tests can be skipped for now, so it's not blocking.

[matthew-brett]

@rgommers - do these look like OpenBLAS errors do you think? Would it be worth testing with lapack-liite? @Mugundanmcw @khmyznikov - do you have any interest in testing here?

[rgommers]

Could be, but could equally well be inside numpy. Ideally this is reproduced locally and then a stack trace generated. Or even in CI, since it reproducibly crashes there and it seems like the "Windows way" of getting a stack trace is to modify the code - once that's done, may as well push it to CI.

Switching to lapack_lite by passing -Csetup-args=blas=none to a build is a reasonable proxy, but doesn't get you any more info than whether it's more or less likely to be in OpenBLAS or in NumPy.

[theAeon]

Currently giving it a go with Arm's blas to see what happens.