[python-rst2pdf] fails with 0xc000001d illegal instruction on GHA ARM worker.

[kasper93]

Description / Steps to reproduce the issue

Recently our CI started failing on ARM.

See: https://github.com/mpv-player/mpv/actions/runs/18630605149/job/53114719940

After adding some logging:

Command: C:\a\_temp\msys64\clangarm64\bin/rst2pdf.EXE -c -b 1 --repeat-table-rows ../DOCS/man/mpv.rst -o mpv.pdf
Return code: 0xc000001d

0xc000001d seems to be illegal instruction.

Used to work recently, looking at build history Oct 17, 9:25 PM GMT+2 is first failing build, while Oct 17, 6:24 PM GMT+2 was still fine.

Expected behavior

rst2pdf.exe works.

Actual behavior

rst2pdf.exe doesn't work.

Verification

• [x] I have verified that my MSYS2 is up-to-date before submitting the report (see https://www.msys2.org/docs/updating/)

Windows Version

.

MINGW environments affected

• [ ] MINGW64
• [ ] MINGW32
• [ ] UCRT64
• [ ] CLANG64
• [x] CLANGARM64

Are you willing to submit a PR?

No response

[lb90]

@kasper93 @lazka

How can I invoke the equivalent of rst2pdf.exe <arguments> using python directly? I tried python -m rst2pdf <arguments> but it fails with:

D:/msys64/clang64/bin/python.exe: No module named rst2pdf.__main__; 'rst2pdf' is a package and cannot be directly executed

[lb90]

I think it's python <path to rt2pdf.exe> <arguments>

[lb90]

The bad instruction is from python-pillow: https://github.com/lb90/mpv/actions/runs/18657817007/job/53191127464

(lldb) target create "python"
Current executable set to 'C:\a\_temp\msys64\clangarm64\bin\python.exe' (aarch64).
(lldb) settings set -- target.run-args  "C:/a/_temp/msys64/clangarm64/bin/rst2pdf.exe" "-c" "-b" "1" "--repeat-table-rows" "DOCS/man/mpv.rst" "-o" "mpv.pdf"
(lldb) run
Process 6456 launched: 'C:\a\_temp\msys64\clangarm64\bin\python.exe' (aarch64)
Process 6456 stopped
* thread #1, stop reason = Exception 0xc000001d encountered at address 0x7fff793b4e70
    frame #0: 0x00007fff793b4e70 _imaging.cp312-mingw_aarch64_ucrt_llvm.pyd`PyInit__imaging + 341404
_imaging.cp312-mingw_aarch64_ucrt_llvm.pyd`PyInit__imaging:
->  0x7fff793b4e70 <+341404>: <unknown> 
    0x7fff793b4e74 <+341408>: st1d   { z0.d }, p0, [x0, z31.d, sxtw]
    0x7fff793b4e78 <+341412>: stnt1d { z0.d }, p4, [x0, #-0x4, mul vl]
    0x7fff793b4e7c <+341416>: <unknown>
(lldb) bt
* thread #1, stop reason = Exception 0xc000001d encountered at address 0x7fff793b4e70
  * frame #0: 0x00007fff793b4e70 _imaging.cp312-mingw_aarch64_ucrt_llvm.pyd`PyInit__imaging + 341404
    frame #1: 0x00007fff7939d8c4 _imaging.cp312-mingw_aarch64_ucrt_llvm.pyd`PyInit__imaging + 245744
    frame #2: 0x00007fff7939d8c4 _imaging.cp312-mingw_aarch64_ucrt_llvm.pyd`PyInit__imaging + 245744
(lldb) quit

[lb90]

I tried disassembling the .pyd with dumpbin /DISASM. Here's part of the output:

  0000000180054E48: D65F03C0  ret
  0000000180054E4C: 51004408  sub         w8,w0,#0x11
  0000000180054E50: 7100111F  cmp         w8,#4
  0000000180054E54: 1A9F27E0  csetlo      w0
  0000000180054E58: D65F03C0  ret
  0000000180054E5C: E59FC000  st1d        {z0.d},p0,[x0,z31.d sxtw]
  0000000180054E60: E59CF000  stnt1d      {z0.d},p4,[x0,#-4,MUL VL]
  0000000180054E64: 000115C8
  0000000180054E68: E59FC000  st1d        {z0.d},p0,[x0,z31.d sxtw]
  0000000180054E6C: E59CF000  stnt1d      {z0.d},p4,[x0,#-4,MUL VL]
  0000000180054E70: 000115B4                                           # <-- IP should be here
  0000000180054E74: E59FC000  st1d        {z0.d},p0,[x0,z31.d sxtw]
  0000000180054E78: E59CF000  stnt1d      {z0.d},p4,[x0,#-4,MUL VL]
  0000000180054E7C: 000115A0
  0000000180054E80: E59FC000  st1d        {z0.d},p0,[x0,z31.d sxtw]
  0000000180054E84: E59CF000  stnt1d      {z0.d},p4,[x0,#-4,MUL VL]
  0000000180054E88: 0001158C
  0000000180054E8C: E59FC000  st1d        {z0.d},p0,[x0,z31.d sxtw]
  0000000180054E90: E59CF000  stnt1d      {z0.d},p4,[x0,#-4,MUL VL]
  0000000180054E94: 00011578

There's no instruction on a few lines, which is strange. Probably dumpbin could not disassemble because the generated code is incorrect?

ARM64 instructions are all 32bit long (fixed-size). The instruction is 0xB4 0x15 0x01 0x00. According to this tool it's not a valid opcode

[kmilos]

Don't know if it's related, but Pillow in 12.0.0 changed a bit how their pyd extensions are built - there is now a new common object that should get linked into some of them via setuptools libraries. I had problems packaging it in LLVM environments, it's possible something goes wrong there? Does it fail in CLANG64 as well, or just on arm64?

[kasper93]

Does it fail in CLANG64 as well, or just on arm64?

Fails only on arm64.

[lb90]

I'd check if the object files in the build directory contain such instructions. I don't have an ARM64 device with me, but maybe we can use CI ;)

EDIT ok, succeeded: https://github.com/lb90/MINGW-packages/actions/runs/18689530592/artifacts/4330255272

[lb90]

Looks like object files do not contain that instruction, only the .pyd files:

$ python /d/bgrep-py/bgrep.py -r b4150100 python-build-CLANGARM64/
python-build-CLANGARM64/build/lib.mingw_aarch64_ucrt_llvm-cpython-312/PIL/_imaging.cp312-mingw_aarch64_ucrt_llvm.pyd:00054268: 00c09fe500f09ce5b415010000c09fe500f09ce5  ....................
python-build-CLANGARM64/build/lib.mingw_aarch64_ucrt_llvm-cpython-312/PIL/_imaging.cp312-mingw_aarch64_ucrt_llvm.pyd:00058e0b: 39490100b9480000b4150100f9e81740f9090140  9I...H.........@...@
python-build-CLANGARM64/build/lib.mingw_aarch64_ucrt_llvm-cpython-312/PIL/_imagingtk.cp312-mingw_aarch64_ucrt_llvm.pyd:00005bc7: 39490100b9480000b4150100f9e81740f9090140  9I...H.........@...@
python-build-CLANGARM64/build/lib.mingw_aarch64_ucrt_llvm-cpython-312/PIL/_webp.cp312-mingw_aarch64_ucrt_llvm.pyd:00006393: 39490100b9480000b4150100f9e81740f9090140  9I...H.........@...@
$

I'm using https://github.com/nneonneo/bgrep, BTW

[kasper93]

Any news about this issue?

[lazka]

I can only offer a revert of the upstream change: #26161

[lazka]

please try again

[kasper93]

please try again

Still doesn't work, see https://github.com/mpv-player/mpv/actions/runs/18997589124/job/54288392203