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

[Alexandre Becoulet]

On Sunday, October 23, 2011 04:54:53 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.

 

> > > 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.

 

> > 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.

 

> 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.

 

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

 

I commited a large patch which should solve these issues. I replaced the lua_State pointer in the Value class with a QPointer<State>. All QPointer objects become null when the State object is destroyed. References in other classes which may still have existing objects when the State is destroyed were replaced as well. I added checks so that performing operations on Value objects with a null QPointer raise an exception (copying and destruction are still allowed).

 

This change also made possible to add a default constructor Value() which enables writing code like this:

 

Value a = b;

 

This may be useful when using the Value class with some generic templates which rely on this.

 

Cleanup job is now left to lua_close, as you suggested.

 

Best,

 

--

Alexandre