Repository navigation
Conversation
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.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes the SIGSEGV in
allocated_values_holding_lua_values_can_be_freed_by_lua_gcon 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 thec_intasrax = (rsp & !0xffff_ffff) + 1, which the x86-64 ABI allows, but LuaJIT'sBC_FUNCCdoeslea RA, [BASE+RD*8]with the fullraxand faults invm_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_luaat opt-level 3 indev(as deps already are), kept at 0 indev-debug. Users' ownUserDatatypes in opt-level-1 crates can still hit this, that needs an upstream fix.