GeezerVison

Tested with

RANLIB="/usr/bin/llvm-ranlib-22" LLVM_PROFDATA="/usr/bin/llvm-profdata-22" LLVM_AR="/usr/bin/llvm-ar-22" CC="clang-22" CXX="clang++-22" LDFLAGS="-fuse-ld=lld-22" ./configure --enable-optimizations --with-lto --enable-shared  && make clean && make -j18

test_call fails on main, passes on this branch. Please help me check if you can. Thank you!

So it seems whether the original bug reproduces on main or not is nondeterministic 😨 . However, I still believe this fix is right.

So it seems whether the original bug reproduces on main or not is nondeterministic 😨 . However, I still believe this fix is right.

I built the Python main branch (without the fix) 3 times in a row from scratch (git clean -fdx): the two first builds didn't reproduce the issue (stack memory per call: 1.2 kB), the 3rd build reproduced the issue (stack memory per call: 33.1 kB).

I built the Python main branch on Fedora Rawhide (clang 22.1.3) with:

./configure --enable-optimizations --with-lto --enable-shared CC=clang LD=clang
time make -j14

On the two first builds, LD_LIBRARY_PATH=$PWD ./python -m test -v test_call test passed successfully (expected: test fails). On the 3rd build, the test failed.

Script:

import _testcapi
import functools

def py_call():
    return _testcapi.stack_pointer()

def call():
    return py_call()

start = _testcapi.stack_pointer()
call = functools.partial(call)
top = call()
diff = start - top
print("stack memory per call: %.1f kB" % (diff / 1024))

Output on the first two builds:

stack memory per call: 1.2 kB

Output on the third build:

stack memory per call: 33.1 kB

Note: I installed clang and its dependencies using sudo dnf install clang llvm-ar compiler-rt.

To get a more reproducible output, I tried using ./python -I -c pass as the "profile task".

Using ./configure --enable-optimizations --with-lto --enable-shared CC=clang LD=clang PROFILE_TASK='-I -c pass', I get a smaller stack memory usage: stack memory per call: 0.8 kB.

I built the Python main branch 3 times with these options and I got the same result each time: test_call pass and stack memory per call: 0.8 kB. I don't reproduce the issue with these options.

Ok, now testing the fix. I built Python with the fix 5 times in a row and test_call succeeded each time. The fix is reliable!

• Build 1: success (stack memory per call: 1.2 kB)
• Build 2: success (stack memory per call: 1.2 kB)
• Build 3: success (stack memory per call: 1.2 kB)
• Build 4: success (stack memory per call: 1.2 kB)
• Build 5: success (stack memory per call: 1.2 kB)

Commands:

./configure --enable-optimizations --with-lto --enable-shared CC=clang LD=clang
time make -j14
LD_LIBRARY_PATH=$PWD ./python -m test -v test_call

Result: test_call pass successfully and my script outputs stack memory per call: 1.2 kB.

Moreover, the C flags are set as expected in Makefile:

$ grep ^CFLAGS_CEVAL Makefile
CFLAGS_CEVAL= -finline-max-stacksize=512

Thanks @vstinner for the very thorough testing and review :).

Thanks @Fidget-Spinner for the PR 🌮🎉.. I'm working now to backport this PR to: 3.14.
🐍🍒⛏🤖

GH-148349 is a backport of this pull request to the 3.14 branch.

Since the bug occurs randomly on clang 22 (coarse estimation 1/3 builds affected), I double checked clang 21.

I built the Python main branch (without the fix) multiple times on Fedora Stable (clang 21.1.8): I failed to reproduce the issue. I confirm that the issue is specific to clang 22.

• Build 1: success (stack memory per call: 1.2 kB)
• Build 2: success (stack memory per call: 1.2 kB)
• Build 3: success (stack memory per call: 1.2 kB)
• Build 4: success (stack memory per call: 1.2 kB)
• Build 5: success (stack memory per call: 1.2 kB)

By the way, we do have Fedora Rawhide Clang buildbots (AArch64, AMD64, PPC64LE, s390x) with Clang 22.1.3, but they don't test the LTO+PGO case:

• "Clang" flavor tests ./configure CC=clang LD=clang --with-pydebug (clang -Og)
• "Clang Installed" flavor tests ./configure CC=clang LD=clang (clang -O3)

@vstinner if you want to test. 3.14 reliably crashes every single time I build with clang-22 before my patch was applied (ie at commit 429c1d3) You can try it out with clang-21 to see if it crashes.

@vstinner if you want to test. 3.14 reliably crashes every single time I build with clang-22 before my patch was applied (ie at commit 429c1d3) You can try it out with clang-21 to see if it crashes.

I built the commit 429c1d3 wih clang 21 (Fedora Stable): I failed to reproduce the issue, test_call pass successfully and my script gives stack memory per call: 2.3 kB.