[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Alexandre Becoulet
Subject: Re: [Libqtlua-list] Lingering QtLua::Functions after QtLua::State cleans the environment
Date: Sat, 03 Dec 2011 13:31:27 +0100
User-agent: KMail/4.7.1 (Linux/3.0-ARCH; KDE/4.7.1; x86_64; ; )

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

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







reply via email to

[Prev in Thread] Current Thread [Next in Thread]