Stack overflow error from recursion with 3.14.0rc1 on MacOS

[cdce8p]

Crash report

What happened?

In the pylint / astroid test suite we have a regression test for a common recursion issue on our end. Though the code triggers a deep recursion, so far CPython was still able to resolve it. While getting ready for 3.14, I noticed that a specific test started to crash Python but only on MacOS. Isolated Github action CI runs seem to confirm this, Ubuntu, Windows are completely fine both with 3.13.6 and 3.14.0rc1. However MacOS only passes with 3.13.6 while failing 3.14.0rc1. Noticeable 3.14.0a6 seems to be the last version which reliably still succeeded.

The releases have been downloaded from python.org; used the actions/setup-python action for tests in CI.

To bisect the issue further, I compiled 3.14.0rc1 on my Mac. Strangely though the test now passes, on the same system where the binary from python.org failed previously.

Local tests done with

• MacOS 14 on M2 Pro
• Python 3.14.0rc1 (v3.14.0rc1:48f88310044, Jul 22 2025, 13:06:29) [Clang 16.0.0 (clang-1600.0.26.6)] from https://www.python.org/downloads/release/python-3140rc1/ => test fails
• Python 3.14.0rc1 (tags/v3.14.0rc1:48f88310044, Aug 9 2025, 00:54:21) [Clang 16.0.6 ] compiled manually => test succeeds

CC=/opt/homebrew/opt/llvm@16/bin/clang ./configure --with-openssl=$(brew --prefix openssl@3) --enable-optimizations --with-lto
make -j4 -s

Run the test case

git clone --depth 1 --branch v4.0.0b2 https://github.com/pylint-dev/astroid.git
cd astroid
python -m venv venv
source venv/bin/activate
pip install pytest==8.4.1 .
pytest tests/test_inference.py::test_recursion_on_inference_tip

Output with 3.14.0rc1 from python.org

(venv) MyMacBook-Pro:astroid $ pytest -s tests/test_inference.py::test_recursion_on_inference_tip
============================== test session starts ===================================
platform darwin -- Python 3.14.0rc1, pytest-8.4.1, pluggy-1.6.0
rootdir: /.../astroid
configfile: pyproject.toml
collected 1 item 

tests/test_inference.py Fatal Python error: _Py_CheckRecursiveCall: Unrecoverable stack overflow (used 3953 kB)
Python runtime state: initialized

Current thread 0x00000001dc071ec0 (most recent call first):
 File "/.../astroid/astroid/decorators.py", line 81 in inner
 File "/.../astroid/astroid/nodes/node_classes.py", line 451 in _infer
 ...
 File "/.../astroid/astroid/decorators.py", line 44 in wrapped
 File "/.../astroid/astroid/decorators.py", line 81 in inner
Abort trap: 6

Output with 3.14.0rc1 compiled locally

tests/test_inference.py::test_recursion_on_inference_tip PASSED

--
I'd be grateful about any pointers to things I'm doing "wrong" in my local build that prevent me from reproducing and bisecting the issue.

CPython versions tested on:

3.14

Operating systems tested on:

macOS

Output from running 'python -VV' on the command line:

Python 3.14.0rc1 (v3.14.0rc1:48f88310044, Jul 22 2025, 13:06:29) [Clang 16.0.0 (clang-1600.0.26.6)]

Linked PRs

• GH-137573: Check C stack depth before stack allocating JIT optimizer struct #137676
• GH-137573: Add test to check that the margin used for overflow protection is larger than the stack space used by the interpreter #137724
• GH-137573: mark _PyOptimizer_Optimize as no inline #137731
• [3.14] GH-137573: mark _PyOptimizer_Optimize as no inline (GH-137731) #137751
• [3.14] GH-137573: Add test to check that the margin used for overflow protection is larger than the stack space used by the interpreter (GH-137724) #139295

[inventshah]

I think the key change between 3.14.0a6 and 3.14.0b1 is compiling with --enable-experimental-jit=yes-off (#131751 (review)).

Reproduce locally with: ./configure -C --enable-experimental-jit=yes-off --with-lto=full --enable-optimizations. Note all three flags seem necessary.

I ran git bisect between bfcbb28 (last commit that touches Tools/jit/_llvm.py) and 1878fe8. The first bad commit is: a5274cd.

One maybe relevant tidbit the JIT docs mention LLVM 19 as required but the python.org MacOS builds are compiled with clang 16?

[inventshah]

Looks like builtin dunder calls cause the recursion limit to be hit much sooner than it should. Removing __getattribute__ from UninferableBase fixes the test in OP, but breaks other tests. In the other issue for pyclibrary, removing one __str__ call in a dependency also fixes the test reported.

A minimal repro is

class Foo:
 def __str__(self):
 return str(self)
str(Foo())

This aborts after 144 calls, while redefining str like def str(x): return x.__str__(), reports RecursionError: maximum recursion depth exceeded as expected (and completes the 1000 allowed). 3.13 raises a RecursionError in both cases.

@hugovk since you asked about a minimal code example in the other issue, and I think these are all related.

[AA-Turner]

Confirming that on Windows the example fails properly with a RecursionError:

Python 3.14.0rc1 (tags/v3.14.0rc1:48f8831, Jul 22 2025, 17:09:57) [MSC v.1944 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> class Foo:
... def __str__(self):
... return str(self)
...
>>> str(Foo())
Traceback (most recent call last):
 File "<python-input-1>", line 1, in <module>
 str(Foo())
 ~~~^^^^^^^
 File "<python-input-0>", line 3, in __str__
 return str(self)
 File "<python-input-0>", line 3, in __str__
 return str(self)
 File "<python-input-0>", line 3, in __str__
 return str(self)
 [Previous line repeated 991 more times]
RecursionError: maximum recursion depth exceeded

[AA-Turner]

cc @markshannon for a5274cd (GH-135225)

[inventshah]

I guess the problem isn't exactly in recursion, but rather something about the stack use of dunder calls. I had also set up a chain of 144 nested classes that subsequently call a child's str (something that should not error, and is probably more akin to whats happening in the failed tests). That hits RecursionError: Stack overflow, while one fewer nested class works.

Click to expand class generator

 template = """
 class A{idx}:
 x{idx} = A{idx2}()
 def __str__(self):
 return str(self.x{idx})
 """
 
 with open("repro.py", "w") as f:
 f.write(
 """
 class A0:
 def __str__(self):
 return "here"
 """
 )
 for idx in range(1, 143):
 f.write(template.format(idx=idx, idx2=idx - 1))
 
 f.write(f"print(A{idx}())")

[encukou]

#131543 looks similar.

[inventshah]

Looks like in 3.14.0b1 we can have a chain of 376 classes, while in the 3.14.0rc1 only 144. FWIW, there is this comment about lto in configure so maybe --with-lto=full is broken (when I compile with thin it seems to be fine...)

cpython/configure

Lines 8410 to 8413 in 3626928

	# Intentionally not forcing Py_LTO='true' here. Too many toolchains do not
	# compile working code using it and both test_distutils and test_gdb are
	# broken when you do manage to get a toolchain that works with it. People
	# who want LTO need to use --with-lto themselves.

Also, the main testsuite has failures, like test_isinstance.TestIsInstanceIsSubclass.test_infinite_cycle_in_bases, so this should be catchable via CI.