lb90

I think it's `python `

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"...

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:...

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,...

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:...

Hi! errno 13 corresponds to [EACCES (permission denied)](https://learn.microsoft.com/en-us/cpp/c-runtime-library/errno-constants?view=msvc-170) What's the output of: ``` env | grep -i tmp env | grep -i temp ```

Looks like tmpfile from msvcrt tries to create files under `C:\`, which would explain why one then gets EACCES. See https://sourceforge.net/p/mingw-w64/bugs/921/

Can you check the exit code with `echo $?`? ``` $ gcc test.c $ echo $? ``` You can also try running gcc within gdb. Install mingw-w64-ucrt-x86_64-gdb and run: ```...

Hi! Sort of, yes. The CRT must flush all open FILE streams on application exit (as required by the C standard). However that final flush is not very safe... it's...

@lazka can you reproduce under a debugger? If so, try setting a breakpoint on `ZwTerminateProcess` (or `NtTerminateProcess`). Normally it's called only one time, but in case of abrupt exit it's...