In LuaObject's contructors and assignment operators, if src LuaObject happens to come from a coroutine then this LuaObject LuaState L will point to freed memory once the coroutine is garbage collected. Which results in all kinds of nasty business, especially in production code :(
From reading the reference, it appears that using lua_pushthread's return value of 1 for a non-coroutine lua_State should help identify that case and lua_xmove should transfer the object for a proper fastref in this's LuaObject's LuaState.
|
inline LuaObject::LuaObject(const LuaObject& src) throw() { |
|
if (src.L) { |
|
L = src.L; |
|
#if LUA_FASTREF_SUPPORT |
|
ref = lua_fastrefindex(L, src.ref); |
|
#else |
|
lua_getfastref(L, src.ref); |
|
ref = lua_fastref(L); |
|
#endif // LUA_FASTREF_SUPPORT |
|
} else { |
|
L = NULL; |
|
ref = LUA_FASTREFNIL; |
|
} |
|
} |
In LuaObject's contructors and assignment operators, if src LuaObject happens to come from a coroutine then this LuaObject LuaState L will point to freed memory once the coroutine is garbage collected. Which results in all kinds of nasty business, especially in production code :(
From reading the reference, it appears that using lua_pushthread's return value of 1 for a non-coroutine lua_State should help identify that case and lua_xmove should transfer the object for a proper fastref in this's LuaObject's LuaState.
luaplus51-all/Src/LuaPlus/LuaObject.inl
Lines 76 to 89 in 7eb904c