Re: Possible bug in Lua's Garbage Collector (nope)

[Mike Pall <mikelu-0805@...>]

Patrick Donnelly wrote:
> static int preparethreads (lua_State *L)

I'm not going to comment on this part, because it's hopelessly
obfuscated. I'm pretty sure you can no longer understand the code
you wrote yourself. So consider rewriting it in a more modular
fashion. I.e. divide it up into many smaller and reusable
functions with easily understood stack-effects.

And while you're at it, add a simple function which pretty-prints
all objects on the current stack (with both absolute and relative
stack slot numbers). Insert this at strategic points when
debugging instead of the printf's.

> This lead me to try, as I said earlier, to produce a minimal example
> showing this problem. I haven't been able to yet, however I did get
> some sort of memory leak while try to reproduce the above (and I hope
> it's connected). It's attached. It just needs statically linked to
> Lua.

This is not a memory leak. You are basically creating unique keys
and values (userdata and a table) and storing them into the
registry.

> You can see, even after the final full collect, it's still using 123
> KiloBytes of memory.

Of course the registry holds a strong reference to each userdata,
so they will not be collected.

> The _really_ odd thing is, if you uncomment the
> second lua_settop(L) in "go", all the userdata are finalized:

No, that's not surprising. This is changing the non-relative stack
indexes, so the lua_pushvalue(L, 2) later on doesn't reference the
userdata anymore.

A few more remarks:
- You can directly operate on threads, i.e. lua_newtable(thread).
  No need to use lua_xmove() here.
- The luaL_checkstack() call does not cover all stack slots. You
  are pushing more objects after the 1000 tables.
- You should really turn on Lua/C API checks while you are
  experimenting with tricky stack manipulations.

About your choice of the subject line: ever heard of Occam's Razor?

--Mike