--disable-gil --enable-experimental-jit=yes-off: test_jit_is_active fails
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 77.2k
- Forks
- 35.9k
- PR merge metrics
- PR metrics pending
Description
Bug report
Bug description:
Hello.
When we started to build the JIT in Fedora's Python, we didn't do it for the freethreading build, as I was told it's not yet ready. I circled back to the referenced issue https://github.com/python/cpython/issues/118844 and saw it is long closed. Hence, I tried to build the JIT with the freethreading build as well. It builds fine, but the tests fail:
Re-running test_sys in verbose mode (matching: test_jit_is_active)
test_jit_is_active (test.test_sys.TestSysJIT.test_jit_is_active) ... FAIL
======================================================================
FAIL: test_jit_is_active (test.test_sys.TestSysJIT.test_jit_is_active)
----------------------------------------------------------------------
Traceback (most recent call last):
File "/builddir/build/BUILD/python3.15-3.15.0_a2-build/Python-3.15.0a2/Lib/test/test_sys.py", line 2275, in test_jit_is_active
assert_python_ok("-c", script.format(enabled=available), PYTHON_JIT="1")
~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/builddir/build/BUILD/python3.15-3.15.0_a2-build/Python-3.15.0a2/Lib/test/support/script_helper.py", line 182, in assert_python_ok
return _assert_python(True, *args, **env_vars)
File "/builddir/build/BUILD/python3.15-3.15.0_a2-build/Python-3.15.0a2/Lib/test/support/script_helper.py", line 167, in _assert_python
res.fail(cmd_line)
~~~~~~~~^^^^^^^^^^
File "/builddir/build/BUILD/python3.15-3.15.0_a2-build/Python-3.15.0a2/Lib/test/support/script_helper.py", line 80, in fail
raise AssertionError(f"Process return code is {exitcode}\n"
...<10 lines>...
f"---")
AssertionError: Process return code is 1
command line: ['/builddir/build/BUILD/python3.15-3.15.0_a2-build/Python-3.15.0a2/build/freethreading-debug/python', '-X', 'faulthandler', '-c', '\nimport _testcapi\nimport _testinternalcapi\nimport sys\n\ndef frame_0_interpreter() -> None:\n assert sys._jit.is_active() is False\n\ndef frame_1_interpreter() -> None:\n assert sys._jit.is_active() is False\n frame_0_interpreter()\n assert sys._jit.is_active() is False\n\ndef frame_2_jit(expected: bool) -> None:\n # Inlined into the last loop of frame_3_jit:\n assert sys._jit.is_active() is expected\n # Insert C frame:\n _testcapi.pyobject_vectorcall(frame_1_interpreter, None, None)\n assert sys._jit.is_active() is expected\n\ndef frame_3_jit() -> None:\n # JITs just before the last loop:\n # 1 extra iteration for tracing.\n for i in range(_testinternalcapi.TIER2_THRESHOLD + 2):\n # Careful, doing this in the reverse order breaks tracing:\n expected = True and i >= _testinternalcapi.TIER2_THRESHOLD + 1\n assert sys._jit.is_active() is expected\n frame_2_jit(expected)\n assert sys._jit.is_active() is expected\n\ndef frame_4_interpreter() -> None:\n assert sys._jit.is_active() is False\n frame_3_jit()\n assert sys._jit.is_active() is False\n\nassert sys._jit.is_active() is False\nframe_4_interpreter()\nassert sys._jit.is_active() is False\n']
stdout:
---
---
stderr:
---
Traceback (most recent call last):
File "<string>", line 37, in <module>
frame_4_interpreter()
~~~~~~~~~~~~~~~~~~~^^
File "<string>", line 33, in frame_4_interpreter
frame_3_jit()
~~~~~~~~~~~^^
File "<string>", line 27, in frame_3_jit
assert sys._jit.is_active() is expected
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError
---
----------------------------------------------------------------------
Ran 1 test in 0.672s
FAILED (failures=1)
test test_sys failed
1 test failed again:
test_sys
== Tests result: FAILURE then FAILURE ==
This is a build --with-pydebug --disable-gil --enable-experimental-jit=yes-off. An optimized build without pydebug behaves the same way. I am also testing with Python 3.14.
A full log with testinfo: build.log
The same test failure happens both on x86_64 and aarch64 Fedora. This is 3.15.0a2.
CPython versions tested on:
3.15
Operating systems tested on:
Linux
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with Lib/test/test_sys.py and TestSysJIT.test_jit_is_active, then reproduce the failure using --with-pydebug --disable-gil --enable-experimental-jit=yes-off. Compare the reported behavior on freethreading builds with the test's expected JIT state across the traced loop and interpreter calls. Done means the test passes for the affected build configurations on the reported architectures.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- compilers
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 42/100