Re: OP_NEWTABLE > __gc > lua_getinfo > getfuncname fails assert

[Dave Hayden <dave@...>]

> On Jun 14, 2016, at 8:20 AM, Roberto Ierusalimschy <roberto@inf.puc-rio.br> wrote:
> 
>> On Jun 13, 2016, at 4:04 PM, Sean Conner <sean@conman.org> wrote:
>>> 
>>> 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. 
>> 
>> Oh, good point! I’m logging the stack trace in realloc, and since Lua frees memory by reallocing the block to zero bytes it was logging there too. I’ll just skip the trace if size is zero. As you say, knowing where it was freed isn’t really useful.
> 
> Not being useful does not imply it should generate an error. This may
> be a bug; I will check it.

I found a place where my “skip lua_getinfo() if realloc size is zero” fix fails, just to add another use (or abuse) case. I’m doing reference counting in the registry by using formatted strings, like “<source>-<key>” -> target. When the source object is collected, it clears the reference from the registry, which might wind up allocing a string, and then my alloc logger calls lua_getinfo().

Your call whether that’s a bug or abusing the API. :)

-D