Re: OP_NEWTABLE > __gc > lua_getinfo > getfuncname fails assert

[Sean Conner <sean@...>]

It was thus said that the Great Dave Hayden once stated:

> I have a __gc function implemented in C that logs allocs and frees,
> calling lua_getinfo() to get a stack trace. In this case, the finalizer is
> being called via the checkGC() call in OP_NEWTABLE in luaV_execute. The
> assert claims that getfuncname() shouldn’t be called from OP_NEWTABLE, but
> this seems like a legit use case. (OP_CONCAT and OP_CLOSURE also call
> checkGC(); OP_CLOSURE would fail the assert, too.)
> 
> Bug, or am I doing it wrong? Or do you need more info?

  I don't think that will give you any valid information.  GC happens
asynchronously from the program (well, it can be viewed that way).  For
instance:

	o = new_object() -- something with a metatable and a __gc method
	o = nil

  The __gc() method isn't called when o is set to nil.  It just dereferences
the object from it's "container" (so to speak).  At some point in the
future, when the GC does run, the GC will notice that there are no more
references to the object, and then call its __gc() method.  So obtaining a
stack trace when __gc is called isn't really a valid thing to do generally. 
Sure, someone *could* do:

	o = new_object()
	o.__gc()
	o = nil

but the whole point of GC is to avoid manual tracking of memory.

  -spc (What are you trying to do?)