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.

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

JIT build crashes on Windows on Arm #129964

Closed
diegorusso opened this issue Feb 10, 2025 · 3 comments
Closed

JIT build crashes on Windows on Arm #129964

diegorusso opened this issue Feb 10, 2025 · 3 comments
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) OS-windows topic-JIT type-crash A hard crash of the interpreter, possibly with a core dump

Comments

@diegorusso
Copy link
Contributor

diegorusso commented Feb 10, 2025

Crash report

What happened?

The JIT on Windows on Arm (tested on Windows 11 Pro) is broken. It builds successfully but then the first test fails straightaway crashing the binary.

Also if I run the REPL and start typing commands, it stays alive for a few seconds and then dies.

When Python is built without the JIT, the test suite passes.

PS C:\Users\ent-user\cpython> .\PCbuild\build.bat -p ARM64 --experimental-jit
....
....
  Generating code
  Finished generating code
  python.vcxproj -> C:\Users\ent-user\cpython\PCbuild\arm64\python.exe
  Wrote C:\Users\ent-user\cpython\PCbuild\arm64\LICENSE.txt
  Generating code
  Finished generating code
  pythonw.vcxproj -> C:\Users\ent-user\cpython\PCbuild\arm64\pythonw.exeBuild succeeded.C:\Users\ent-user\cpython\Python\optimizer_symbols.c(487,20): warning C4244: 'return': conversion from 'Py_ssize_t' to
'int', possible loss of data [C:\Users\ent-user\cpython\PCbuild\pythoncore.vcxproj]
    1 Warning(s)
    0 Error(s)Time Elapsed 00:02:07.70


PS C:\Users\ent-user\cpython> .\python.bat -m test
Running Release|ARM64 interpreter...
== CPython 3.14.0a4+ (heads/main:d7672e5d5a, Feb 10 2025, 15:21:49) [MSC v.1940 64 bit (ARM64)]
== Windows-11-10.0.26100-SP0 little-endian
== Python build: release with_assert
== cwd: C:\Users\ent-user\cpython\build\test_python_worker_5516æ
== CPU count: 8
== encodings: locale=cp1252 FS=utf-8
== resources: all test resources are disabled, use -u option to unskip tests
Using random seed: 1919085789
0:00:00 Run 484 tests sequentially in a single process
0:00:00 [  1/484] test.test_asyncio.test_base_events
Windows fatal exception: access violation
Thread 0x0000093c (most recent call first):
  File "C:\Users\ent-user\cpython\Lib\linecache.py", line 75 in checkcache
  File "C:\Users\ent-user\cpython\Lib\traceback.py", line 487 in _extract_from_extended_frame_gen
  File "C:\Users\ent-user\cpython\Lib\traceback.py", line 445 in extract
  File "C:\Users\ent-user\cpython\Lib\asyncio\format_helpers.py", line 80 in extract_stack
  File "C:\Users\ent-user\cpython\Lib\asyncio\events.py", line 55 in __init__
  File "C:\Users\ent-user\cpython\Lib\asyncio\events.py", line 123 in __init__
  File "__init__", line ??? in __init__
  File "C:\Users\ent-user\cpython\Lib\asyncio\base_events.py", line 875 in call_soon_threadsafe
  File "C:\Users\ent-user\cpython\Lib\asyncio\base_events.py", line 2062 in set_debug
  File "C:\Users\ent-user\cpython\Lib\test\test_asyncio\test_base_events.py", line 310 in check_thread
  File "C:\Users\ent-user\cpython\Lib\test\test_asyncio\test_base_events.py", line 340 in check_in_thread
  File "C:\Users\ent-user\cpython\Lib\threading.py", line 996 in run
  File "C:\Users\ent-user\cpython\Lib\threading.py", line 1054 in _bootstrap_inner
  File "C:\Users\ent-user\cpython\Lib\threading.py", line 1016 in _bootstrap
Thread 0x00003824 (most recent call first):
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\win_utils.py", line 47 in _update_load
Current thread 0x00001db8 (most recent call first):
  File "C:\Users\ent-user\cpython\Lib\asyncio\base_events.py", line 1965 in _run_once
  File "C:\Users\ent-user\cpython\Lib\asyncio\base_events.py", line 677 in run_forever
  File "C:\Users\ent-user\cpython\Lib\asyncio\base_events.py", line 706 in run_until_complete
  File "C:\Users\ent-user\cpython\Lib\test\test_asyncio\test_base_events.py", line 353 in test_thread
  File "C:\Users\ent-user\cpython\Lib\test\test_asyncio\test_base_events.py", line 360 in test_check_thread
  File "C:\Users\ent-user\cpython\Lib\unittest\case.py", line 606 in _callTestMethod
  File "C:\Users\ent-user\cpython\Lib\unittest\case.py", line 660 in run
  File "C:\Users\ent-user\cpython\Lib\unittest\case.py", line 716 in __call__
  File "C:\Users\ent-user\cpython\Lib\unittest\suite.py", line 122 in run
  File "C:\Users\ent-user\cpython\Lib\unittest\suite.py", line 84 in __call__
  File "C:\Users\ent-user\cpython\Lib\unittest\suite.py", line 122 in run
  File "C:\Users\ent-user\cpython\Lib\unittest\suite.py", line 84 in __call__
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\testresult.py", line 148 in run
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\single.py", line 84 in _run_suite
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\single.py", line 42 in run_unittest
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\single.py", line 162 in test_func
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\single.py", line 118 in regrtest_runner
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\single.py", line 165 in _load_run_test
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\single.py", line 210 in _runtest_env_changed_exc
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\single.py", line 319 in _runtest
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\single.py", line 348 in run_single_test
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\main.py", line 378 in run_test
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\main.py", line 412 in run_tests_sequentially
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\main.py", line 559 in _run_tests
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\main.py", line 594 in run_tests
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\main.py", line 766 in main
  File "C:\Users\ent-user\cpython\Lib\test\libregrtest\main.py", line 774 in main
  File "C:\Users\ent-user\cpython\Lib\test\__main__.py", line 2 in <module>
  File "<frozen runpy>", line 88 in _run_code
  File "<frozen runpy>", line 198 in _run_module_as_main
PS C:\Users\ent-user\cpython> 

CPython versions tested on:

CPython main branch

Operating systems tested on:

Windows

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

.\python.bat -VV
Running Release|ARM64 interpreter...
Python 3.14.0a4+ (heads/main:d7672e5d5a, Feb 10 2025, 15:21:49) [MSC v.1940 64 bit (ARM64)]

Linked PRs

@diegorusso diegorusso added interpreter-core (Objects, Python, Grammar, and Parser dirs) OS-windows topic-JIT type-crash A hard crash of the interpreter, possibly with a core dump labels Feb 10, 2025
@brandtbucher
Copy link
Member

Yeah, this is one of the downsides of building, but not testing, this. Did you want to dig into it, or should I?

I'm guessing we're just relocating something wrong after both of our Clang upgrades. Hopefully something a manual review of the stencils can shake out.

@diegorusso
Copy link
Contributor Author

I'm off until Tuesday, I can take a look next week.
I have now a WoA VM on my mac, so getting access to a WoA machine it will be easier :)

@diegorusso
Copy link
Contributor Author

diegorusso commented Mar 5, 2025

After installing all dependencies and setup the environment on WoA, I was able to compile and run CPython with debug. It crashes here:

Assertion failed: (int64_t)value < (1 << 20), file C:\Users\dierus01\cpython\Python\jit.c, line 313 

After some debugging with Brandt we saw that basically the value to patch was returning a huge number hence the assert was failing. We tested it with clang-18 and it was working as expected. So it was a change of code generation between clang-18 and clang-19.

Eventually Brandt found that -fplt restores the clang 18 behaviour.

PR is coming.

diegorusso added a commit to diegorusso/cpython that referenced this issue Mar 5, 2025
Updating to clang-19 change the code generation of the JIT stencils.
This caused some addresses of symbols to be far away hence it was
impossible to reach them out.
Enabling the -fplt restores the behaviour that we had with clang-18.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interpreter-core (Objects, Python, Grammar, and Parser dirs) OS-windows topic-JIT type-crash A hard crash of the interpreter, possibly with a core dump
Projects
None yet
Development

No branches or pull requests

2 participants