Re: Weak tables and userdata finalization

[冶晶邓 <fatfatson@...>]

hi, mark & Gregory ~

maybe i have the similar problem with you..

i also use a weak table to save the map between c++ object address to its lua table,

every c++ object is represented as a lua table, whose array part element[1] is a userdata for saving the c++ object's address,

and the __gc method for the userdata is set for calling the object's ref-counter decrease

at most time it goes well, but if i adjust the gc parameter "setpause" to a little value, some strange crash would happen, and the dump looks like a memory corrupt.

i have no much knownodge about lua gc, so what's your conclusion for the problem? is my c++ bind solution correct ?

thanks~

 

 

2011/9/4 Mark Hamburg <mark@grubmah.com>

On Sep 3, 2011, at 3:13 PM, Gregory Bonik wrote:

> Mark Hamburg wrote:
>> The actual case we were dealing with:
>>
>> View system userdata objects have Lua environments to couple them into
>> the Lua logic. These point to other objects supplying values through a
>> binding mechanism. In particular, we can have value suppliers
>> supplying images which are themselves represented with userdata
>> objects.
>>
>> Collecting the view data preserves its environment which preserves the
>> value supplier but doesn't keep the image being supplied from being
>> finalized. Code comes along and constructs a new view which wants to
>> find a supplier for a particular image and gets the cached which leads
>> to it try to use a finalized image.
>
> If I understand correctly the case, there is another problem here. It
> can happen so that the new view is allocated exactly at the same address
> as the old one. As I can conclude from you original post, you have a
> mapping (via a weak table) from the lightuserdata addresses to the env
> tables of the views.
>
> Suppose that GC finalizes old view's userdata but keeps its env table,
> then a new view with the same address is constructed and mapped to the
> env table of the old defunct view.

Not a problem, the table goes from light userdata (the view) to full userdata (the Lua-side proxy) and from that we go to the environment.

>
> I my case, I have a sort of "indirect" cache: C++ object addresses are
> mapped to env tables via a special weak table. Env tables are used to
> store Lua callbacks connected to objects. Multiple userdata can
> represent the same object, so they share the same env table. These
> userdata do not have a finalizer. Instead, a special userdata is
> referenced from each env table. Its sole purpose is to decrement C++
> object's reference count in the finalizer. Everything went fine until
> the memory allocator started to reuse disposed memory for new objects.

Yeah. We're safe from that because the existence of the non-finalized Lua proxy will keep the native object alive and the only thing we map to from the native object is that non-finalized Lua proxy.

Mark