Re: [Libqtlua-list] Lingering QtLua::Functions after QtLua::State cleans the environment

[David Palacio]

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 
> lua_State* 
> _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
lua_State anyway.

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
themselves?

> -- 
> Alexandre

Regards,
David