NumPy test failure after upgrading to 3.14.1t on MacOS x86_64

[jorenham]

Bug report

Bug description:

Intially reported at numpy/numpy#30370 and https://discuss.python.org/t/python-3-14-1-is-now-available/105163/6

---

At NumPy there's a test in CI that started failing on MacOS x86_64 after upgrading to 3.14.1t:

actions log: https://github.com/numpy/numpy/actions/runs/19909510040/job/57074363533?pr=30367
failing test: https://github.com/numpy/numpy/blob/4a6bb2d843ba271f09a4115fd2c2c9dc82c78820/numpy/_core/tests/test_dtype.py#L988-L995

def test_tuple_recursion(self):
    d = np.int32
    for i in range(100000):
        d = (d, (1,))
    with pytest.raises(RecursionError):  # <--
        np.dtype(d)

CPython versions tested on:

3.14

Operating systems tested on:

macOS

[ngoldbaum]

Happy to help if there are NumPy internals questions that come up.

[ngoldbaum]

Doesn't trigger on ARM Macs. Unfortunately that means I can't reproduce it or help bisect it on hardware I can easily use :(

[colesbury]

This doesn't look free threading related. It looks like you don't have a 3.14 job in your matrix, just 3.14t.

Is this a bug in Python. It doesn't raise a RecursionError, but it doesn't crash. What's the problem? Does it crash if you raise the iterations?

The recursion check changed between 3.14.0 and 3.14.1:

cpython/Include/internal/pycore_ceval.h

Lines 199 to 203 in ebf955d

	static inline int _Py_MakeRecCheck(PyThreadState *tstate) {
	uintptr_t here_addr = _Py_get_machine_stack_pointer();
	_PyThreadStateImpl *_tstate = (_PyThreadStateImpl *)tstate;
	return here_addr < _tstate->c_stack_soft_limit;
	}

cpython/Include/internal/pycore_ceval.h

Lines 201 to 212 in 57e0d17

	static inline int _Py_MakeRecCheck(PyThreadState *tstate) {
	uintptr_t here_addr = _Py_get_machine_stack_pointer();
	_PyThreadStateImpl *_tstate = (_PyThreadStateImpl *)tstate;
	// Overflow if stack pointer is between soft limit and the base of the hardware stack.
	// If it is below the hardware stack base, assume that we have the wrong stack limits, and do nothing.
	// We could have the wrong stack limits because of limited platform support, or user-space threads.
	#if _Py_STACK_GROWS_DOWN
	return here_addr < _tstate->c_stack_soft_limit && here_addr >= _tstate->c_stack_soft_limit - 2 * _PyOS_STACK_MARGIN_BYTES;
	#else
	return here_addr > _tstate->c_stack_soft_limit && here_addr <= _tstate->c_stack_soft_limit + 2 * _PyOS_STACK_MARGIN_BYTES;
	#endif
	}

[ngoldbaum]

We can just skip this test in numpy. It's testing observed behavior in Python rather than anything that's being relied on in NumPy. See numpy/numpy@bb76bff for context on why the test was added.

[ngoldbaum]

I opened numpy/numpy#30375. IMO you can close this issue.