[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Libqtlua-list] Lingering QtLua::Functions after QtLua::State cleans
Re: [Libqtlua-list] Lingering QtLua::Functions after QtLua::State cleans the environment
Sun, 23 Oct 2011 16:54:53 -0500
On Sun, Oct 23, 2011 at 04:21:02PM +0200, Alexandre Becoulet wrote:
> On Wednesday, October 19, 2011 03:46:45 PM David Palacio wrote:
> Hi David,
> > I bind some C++ QtLua::Functions and some of them are referenced inside Lua
> > modules. These functions may throw an exception (Lua userdata is no
> > QtLua::UserData) if they are deleted when the State is being deleted. I
> > tracked the problem to a non existant metatable State::_key_item_metatable
> > in the registry. This check in qtluauserdata.cc:51 fails:
> > The State::_key_item_metatable metatable is already deleted so this check
> > fails.
> Can you provide a testcase?
I have not been able to make a small testcase. Sorry about that. The attached
testcase requires the program located at https://github.com/dpalacio/luaplasma
with the QObject patches and without the State destructor patch. Dependencies
are QtLua, xdg-basedir and Plasma libraries. Current commit is 91a9c55.
You may modify the install prefix in the file src/src.pro.
To run the testcase:
/path/to/luaplasma -rc /path/to/test.lua
The QtLua::Function in the testcase survives the ~State() cleaning by having a
reference in the closure of the "quitting" Lua function.
The use of local variables is to protect the module functions in case of the
user tampers the global variables.
> > So, who deletes the metatable? QtLua::State does. May I know what for? Since
> > Lua should be able to take care of cleaning the environment and calling gc
> > methods when lua_close is called. I attach a patch that leaves the cleaning
> > responsability to lua_close.
> There are issues with some QtLua::Value objects:
> * Those which are not referenced by a lua variable but only referenced from
> C++ smart pointer at the time lua_close is called
> * Those which were not dynamically allocated.
> These objects won't be destroyed by lua_close and will access their
> _st pointer later and cause a crash. It's up to the programmer to ensure that
> all Value objects are freed before the associated State is. This check helps
> finding orphaned Value objects.
> An other approache would be to set _st pointer to NULL for all existing Value
> objects in ~State and checking the pointer validity on Value operations. It's
> not clear which behavior would be appropriate when _st became NULL.
Since Value (C++) objects access the state in their destructor I do not see how
the State destructor helps here. Any external Value reference will access the
UserData objects could be invalidated in State::lua_meta_item_gc, even if the
pointed object is not destroyed.
By the way, I see that Value objects get the parent State via a reference in the
registry. Is there a reason that they do not hold a pointer to the State