Open checkraisefold opened 5 months ago
There's a big problem with Lua references: they are not thread safe. No lua_lock
used when doing luaL_ref
and luaL_unref
. So unless you protect Lua registry usage with locks yourself, you will get strange crashes while creating/destroying sol references from several threads. You can debug it with looking at the registry with my script. Note that the registry sometimes gets corrupted well before the crash. Also note that using the references (lua_rawgeti
) seems thread safe.
There's a big problem with Lua references: they are not thread safe. No
lua_lock
used when doingluaL_ref
andluaL_unref
. So unless you protect Lua registry usage with locks yourself, you will get strange crashes while creating/destroying sol references from several threads. You can debug it with looking at the registry with my script. Note that the registry sometimes gets corrupted well before the crash. Also note that using the references (lua_rawgeti
) seems thread safe.
The problem is that the 'RosaServer' project this thing is happening in is entirely single threaded except for the thread that handles console input, and it just uses detours on the game dedicated server it's a mod for. So there's no cross-thread refs going on here
This issue is seemingly very hard to debug, and I'm unable to produce a test case for this (considering this usage of sol2 is pretty out of the ordinary and this is the only instance of this crash I'm able to find) The code causing the crash: https://github.com/jpxs-intl/RosaServer/blob/main/RosaServer/hooks.cpp#L1293 where
run
is a sol2 protected_function, changeable from the Lua environment. This issue also doesn't persist in a debug build, and only happens in release mode. I've gathered the debug info with GCC-g
compiler option.Call stack:
I did some debugging, and while the
![devenv_dikVq5T5Fm](https://github.com/ThePhD/sol2/assets/19525688/49f3d380-80f4-48bc-97b6-e292373de7a0)
&Engine::vehicles[vehicleID]
reference passed torun
is perfectly valid and readable memory, the reference seems to be corrupted somehow after the severalstd::forward
parameter unpacks. By the timestack::push_reference
is hit, the Vehicle reference is somehow nulled out. I could just be wrong though, seeing as the segfault is for some reason in.. the constructor for undefined_metatable. See screenshots:The prior
run
call in that function doesn't undergo a similar segfault and runs completely fine.Compiler is GCC, being built with CMake. Using VS2022 as an IDE w/WSL remote development. Version of sol2 is latest
develop
branch, but is reproducible on the latestmaster
as well. Attempted usingSOL_ALL_SAFETIES_ON
just to see if it'd do anything considering it worked in a debug build and had no dice.