Repository navigation
Stack overflow error from recursion with 3.14.0rc1 on MacOS #137573
Description
Activity
I think the key change between
3.14.0a6and3.14.0b1is 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 bisectbetween bfcbb28 (last commit that touchesTools/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?
Looks like builtin dunder calls cause the recursion limit to be hit much sooner than it should. Removing
__getattribute__fromUninferableBasefixes the test in OP, but breaks other tests. In the other issue forpyclibrary, 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
abortsafter 144 calls, while redefiningstrlikedef str(x): return x.__str__(), reportsRecursionError: maximum recursion depth exceededas expected (and completes the 1000 allowed). 3.13 raises aRecursionErrorin both cases.@hugovk since you asked about a minimal code example in the other issue, and I think these are all related.
Reacted by Hugo van Kemenade- marked Segmentation fault on Python 3.14 rc1 on macOS #137617 as a duplicate of this issue
on Aug 11, 2025 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
cc @markshannon for a5274cd (GH-135225)
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}())")Looks like in
3.14.0b1we can have a chain of376classes, while in the3.14.0rc1only144. FWIW, there is this comment about lto in configure so maybe--with-lto=fullis broken (when I compile withthinit seems to be fine...)Lines 8410 to 8413 in 3626928
Also, the main testsuite has failures, like
test_isinstance.TestIsInstanceIsSubclass.test_infinite_cycle_in_bases, so this should be catchable via CI.Ran another
git bisectwith the infinite recursion repro, and ac3c439 is the first bad commit (starting from 3.14.0a05), which looks more relevant than the other commit. Note I still need--enable-experimental-jit=yes-off, which the alphas aren't compiled with, so I think there may be another issue further back or toolchain bug.23 remaining items
- added a commit that references this issue
on Sep 23, 2025 Is there anything left here? I believe all has been resolved and this issue could be closed.
- added a commit that references this issue
on Oct 8, 2025 The backport has been merged.
(A downside of keeping issues open to track backports is merging the backport and forgetting the issue :)
- moved this from Todo to Done in Release and Deferred blockers 🚫
on Oct 10, 2025 - added a commit that references this issue
on Nov 13, 2025 - added a commit that references this issue
on Nov 14, 2025
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,Windowsare completely fine both with3.13.6and3.14.0rc1. However MacOS only passes with3.13.6while failing3.14.0rc1. Noticeable3.14.0a6seems to be the last version which reliably still succeeded.The releases have been downloaded from python.org; used the
actions/setup-pythonaction for tests in CI.To bisect the issue further, I compiled
3.14.0rc1on my Mac. Strangely though the test now passes, on the same system where the binary from python.org failed previously.Local tests done with
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 failsPython 3.14.0rc1 (tags/v3.14.0rc1:48f88310044, Aug 9 2025, 00:54:21) [Clang 16.0.6 ]compiled manually => test succeedsCC=/opt/homebrew/opt/llvm@16/bin/clang ./configure --with-openssl=$(brew --prefix openssl@3) --enable-optimizations --with-lto make -j4 -sRun the test case
Output with
3.14.0rc1from python.orgOutput with
3.14.0rc1compiled locally--
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