Skip to content

fix: LuaJIT segfault collecting userdata in opt-level 1 builds - #734

Open
makspll wants to merge 1 commit into
mainfrom
agent/luajit-gc-segfault
Open

makspll wants to merge 1 commit into
mainfrom
agent/luajit-gc-segfault

Conversation

@makspll

@makspll makspll commented Nov 14, 2026

Copy link
Copy Markdown
Owner

Fixes the SIGSEGV in allocated_values_holding_lua_values_can_be_freed_by_lua_gc on LuaJIT.

Not a BMS bug: any mlua userdata collected by LuaJIT's GC crashes when mlua's __gc (destroy_userdata_storage::<T>, generic, so compiled in the calling crate) is built at opt-level 1. That codegen returns the c_int as rax = (rsp & !0xffff_ffff) + 1, which the x86-64 ABI allows, but LuaJIT's BC_FUNCC does lea RA, [BASE+RD*8] with the full rax and faults in vm_return. Reproduces with plain mlua 0.12.2 + an empty userdata at opt-level 1; still unfixed in LuaJIT v2.1.

Workaround: build bevy_mod_scripting_lua at opt-level 3 in dev (as deps already are), kept at 0 in dev-debug. Users' own UserData types in opt-level-1 crates can still hit this, that needs an upstream fix.

LuaJIT reads the full rax after calling a C function returning int; at
opt-level 1 mlua's generic userdata __gc leaves garbage in its upper half.
Build bevy_mod_scripting_lua at opt-level 3 in dev, like dependencies.
@semanticdiff-com

Copy link
Copy Markdown

Review changes with  SemanticDiff

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant