Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

test_call.test_super_deep started segfaulting with 3.14.0a4 freethreading #128954

Open
mgorny opened this issue Jan 17, 2025 · 4 comments
Open

test_call.test_super_deep started segfaulting with 3.14.0a4 freethreading #128954

mgorny opened this issue Jan 17, 2025 · 4 comments
Labels
tests Tests in the Lib/test dir topic-free-threading type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@mgorny
Copy link
Contributor

mgorny commented Jan 17, 2025 •
edited by bedevere-app bot
Loading

Crash report

What happened?

test_super_deep (test.test_call.TestRecursion.test_super_deep) ... Fatal Python error: Segmentation fault

The test passes with a3 but segfaults with a4 — so I'm guessing stack frames grew or something. Not sure if this is the kind of regression in code that needs to be fixed, or merely recursion limit needs to be lowered.

This is Gentoo Linux amd64, CPython built with LTO + PGO, CFLAGS are -march=znver2 --param=l1-cache-size=32 --param=l1-cache-line-size=64 -O2 -pipe -frecord-gcc-switches.

Full log: dev-lang:python-3.14.0_alpha4-r100:20250117-163521.txt

CPython versions tested on:

3.14

Operating systems tested on:

Linux

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

Python 3.14.0a4 experimental free-threading build (main, Jan 17 2025, 17:46:22) [GCC 14.2.1 20241221]

Linked PRs
@mgorny mgorny added the type-crash A hard crash of the interpreter, possibly with a core dump label Jan 17, 2025
@mgorny
Copy link
Contributor Author

mgorny commented Jan 17, 2025

#127455 seems to indicate that they're hitting a similar problem on Windows.

@picnixz picnixz added tests Tests in the Lib/test dir topic-free-threading labels Jan 17, 2025
@colesbury
Copy link
Contributor

We can lower the recursion limit, but it seems like it'd be good to reduce the stack usage in the free-threading build:

cpython/Include/cpython/pystate.h

Line 232 in d95ba9f

# define Py_C_RECURSION_LIMIT 10000

colesbury added a commit to colesbury/cpython that referenced this issue Jan 17, 2025
@colesbury
pythongh-128954: Reorder _PyInterpreterFrame fields for reduced memor…
e519469 
…y usage

This reduces the size of _PyInterpreterFrame by 8 bytes on 64-bit
platforms using the free threading build due to alignment requirements.

This allows for slightly more recursive calls into the interpreter (from
C), but `test_call.test_super_deep` still crashes.
@bedevere-app bedevere-app bot mentioned this issue Jan 17, 2025
Open
@mgorny
Copy link
Contributor Author

mgorny commented Jan 18, 2025

I'm going to try if bisect can tell what change caused the issue to appear with a4.

@mgorny
Copy link
Contributor Author

mgorny commented Jan 18, 2025

Bisect points to 128cc47:

commit 128cc47fbd44e3e09c50d9674fe4a4bba3be450c (HEAD)
Author:     Mark Shannon <[email protected]>
AuthorDate: 2024-12-20 17:52:20 +0100
Commit:     GitHub <[email protected]>
CommitDate: 2024-12-20 17:52:20 +0100

    GH-127705: Add debug mode for `_PyStackRef`s inspired by HPy debug mode (GH-128121)

CC @markshannon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
tests Tests in the Lib/test dir topic-free-threading type-crash A hard crash of the interpreter, possibly with a core dump
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mgorny @colesbury @picnixz