Re: Weak tables and userdata finalization

[Gregory Bonik <gregory@...>]

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.

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.

-- Gregory