You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The program outputs -1 (or some garbage if additional allocations were performed later), which means destructor of A was called before a1:getI() call. If the line local a1 = getA():fn() is replaced by
locala1=getA()
a1:fn()
the output becomes 5, as expected initially.
Is it a bug of LuaBridge, or Lua itself, or such a chaining is not allowed for some reasons?
The text was updated successfully, but these errors were encountered:
You cannot take a reference of a Lua managed object without making sure you keep it alive in lua land. Lua will have a reference count of 0 for the A created by getA because you are not keeping the refcount alive and it's free to garbage collect it.
Thanks! But it seems like LuaBridge might determine that a pointer or a reference returned from C++ points to an object with Lua lifetime and increment its refcounter. On the other hand, there is a working approach with RefCountedObjectPtr.
It can't, it would need to register each instance of binded classes created from lua into the registry and compare everytime a reference or pointer is to be handled.
Lua GC erroneously (?) deletes an object when Lua still holds a reference on it obtained through a chain of method calls. E. g.:
The program outputs
-1
(or some garbage if additional allocations were performed later), which means destructor ofA
was called beforea1:getI()
call. If the linelocal a1 = getA():fn()
is replaced bythe output becomes
5
, as expected initially.Is it a bug of LuaBridge, or Lua itself, or such a chaining is not allowed for some reasons?
The text was updated successfully, but these errors were encountered: