[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: Sun, 23 Oct 2011 16:21:02 +0200
User-agent: KMail/4.7.1 (Linux/3.0-ARCH; KDE/4.7.1; x86_64; ; )

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 fails:


> The State::_key_item_metatable metatable is already deleted so this check

> fails.


Can you provide a testcase?


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





reply via email to

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