[luajit] Crashes on 32-bit builds

[kasper93]

Description / Steps to reproduce the issue

mpv CI started failing few days ago.
See https://github.com/mpv-player/mpv

Example of crashing build https://github.com/mpv-player/mpv/actions/runs/4836193035/jobs/8619203629

It crashes during loading/executing lua scripts. Wasn't a problem few days ago as we can see on CI history.

Interestingly it is also not caused by recent luajit update, because I reverted this locally to older version and still crashes.

To reproduce:
./mpv.com --no-config -v -v

Expected behavior

No crashes/exceptions

Actual behavior

Crashes/exceptions

Verification

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

Windows Version

MINGW32_NT-10.0-19045

MINGW environments affected

• MINGW64
• MINGW32
• UCRT64
• CLANG64
• CLANG32
• CLANGARM64

Are you willing to submit a PR?

No response

[Biswa96]

The mpv package in mingw32 is working fine.

$ mpv.exe --no-config -v -v
[cplayer] Command line options: '--no-config' '-v' '-v'
[cplayer] mpv 0.35.1 Copyright © 2000-2023 mpv/MPlayer/mplayer2 projects
[cplayer]  built on Tue Mar 14 07:20:51 2023
[cplayer] FFmpeg library versions:
[cplayer]    libavutil       58.2.100
[cplayer]    libavcodec      60.3.100
[cplayer]    libavformat     60.3.100
[cplayer]    libswscale      7.1.100
[cplayer]    libavfilter     9.3.100
[cplayer]    libswresample   4.10.100
[cplayer] FFmpeg version: 6.0
[cplayer]
[cplayer] Configuration: meson configure build -Dprefix=/mingw32 -Dbuildtype=plain -Doptimization=plain
...

[kasper93]

mpv.com --no-config -v -v $videofile

So it works for you with OSD and everything?

[Biswa96]

Wait a sec, I did not notice the return code. It's 127.

[Biswa96]

Perfect, using debug build of luajit fixes the issue 🤦

[revelator]

if a debug build fixes it then it sounds like optimization is breaking something ?.
i've had problems using vector optimizations on 32 bit with some sources but i think this is enabled by default at -O2 so maybe we should try a lower optimization level for 32 bit.

[kasper93]

if a debug build fixes it then it sounds like optimization is breaking something ?.
i've had problems using vector optimizations on 32 bit with some sources but i think this is enabled by default at -O2 so maybe we should try a lower optimization level for 32 bit.

Vector optimizations issues, cause by invalid stack alignment is GCC only bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54412) and is patched in MSYS's provided GCC version. Clang is unaffected as it handles it properly.

For luajit, basically need to find the root cause why it crashes. I've seen that it panic on unwinding stack on error, but it shouldn't error out in the first place. And if optimization is breaking your software it is more likely that you have UB, compilers have pretty good test suites. Now mpv is using lua51 to make CI work again.

[lb90]

If I launch clang32\bin\mpv.exe from File Explorer I get the following "Procedure entry-point could not be located..." messages:

vkCreateDisplayPlaneSurfaceKHR@16 in mpv.exe
vkGetInstanceProcAddr@8 in libplacebo-264.dll

So I guess that #17035 fixes this (with rebuilds of mpv and libplacebo)

[kasper93]

@lb90: Yes, it is #17029 what I did to test locally is to rename C:\Windows\SysWOW64\vulkan-1.dll temporarily to use the loader from msys sysroot which works.

[revelator]

ah vulkan loader problem then :)

[kasper93]

Wait, I think we misunderstood each other. luajit crashes are not related to Vulkan whatsoever. The only relation was that mpv was failing also when loading Vulkan, but the lua crash is still present.

[lb90]

Ah true, sorry! Here's a stacktrace:

(gdb) r
Starting program: D:\msys64\mingw32\bin\mpv.exe 
gdb: unknown target exception 0xc00001a5 at 0x71cc63d3

Thread 8 "mpv/lua script (stats)" received signal ?, Unknown signal.
[Switching to Thread 16640.0x3f08]
0x77b7d6c2 in RaiseException () from C:\WINDOWS\SysWOW64\KernelBase.dll
(gdb) bt
#0  0x77b7d6c2 in RaiseException () from C:\WINDOWS\SysWOW64\KernelBase.dll
#1  0x71cc635e in err_raise_ext (g=<optimized out>, errcode=<optimized out>) at lj_err.c:366
#2  0x71cc6386 in @lj_err_throw@8 (L=0x3c601c8, errcode=<optimized out>) at lj_err.c:743
#3  0x71cfe07c in lj_trace_err_info (J=J@entry=0x3c603b0, e=e@entry=LJ_TRERR_NYIBC) at lj_trace.c:49
#4  0x71cebc71 in lj_record_ins (J=J@entry=0x3c603b0) at lj_record.c:2630
#5  0x71cfe95f in trace_state (L=0x3c601c8, dummy=0x0, ud=0x3c603b0) at lj_trace.c:690
#6  0x71cc307f in lj_vm_cpcall () from D:\msys64\mingw32\bin\lua51.dll
#7  0x03c601c8 in ?? ()
Backtrace stopped: Cannot access memory at address 0x22488795
(gdb) 

[lb90]

The error is thrown from https://github.com/LuaJIT/LuaJIT/blob/224129a/src/lj_record.c#L2630. op is BC_FNEW

@kasper93 could you open an issue upstream?

[kasper93]

@kasper93 could you open an issue upstream?

If it were upstream issue I would report it there in the first place. Upstream build works fine. Anyway I sent PR with the fix for the MSYS build.

[revelator]

the 32 bit unwinder is broken ?!? kinda defeats the purpose of a jit based build then doesnt it ?.
sounds like there is some issue we need to investigate with gcc then or does this also apply to clang ?.