lua-users home
lua-l archive

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

I think that lua_close() runs the GC, doesn't it? So if it can collect
the userdata-bound COM objects, they should be freed as long as they
have a __gc metamethod to free the COM objects themselves. That is, I
don't think it has anything to do with COM, just the garbage
collection of userdata. That would explain why your patch works.

Well, I think so, anyways. I recently wrote an interface to the json-c
library for Lua, and I had to deal with garbage collection myself, so
I -think- I'm right. But hey, if someone has to set me straight,
please do...


On Tue, Mar 2, 2010 at 11:22 PM, Kenneth LO <> wrote:
> So lua_close is the problem.  Just a quick change to loslib.c
> static int os_exit (lua_State *L) {
>  int t = luaL_optint(L, 1, EXIT_SUCCESS);
>  lua_close(L);
>  /* exit(luaL_optint(L, 1, EXIT_SUCCESS)); */
>  exit(t);
> }
> So far it does the job but I'm not sure if there is any memory
> leakage.  The manual says it will free all memory associated with the
> state but does it include those locked in COM and OLE?  In comparison,
> the php manual explicitly says that an exit() will free all memory and
> object destructors will always be executed.  I tried to find out how
> it was implemented from the php source.  But then I gave up.