[PATCH] Bugfix and drop weak references to finalizable objects (was: Re: [PATCH] thread-safe handling of asynchronous events)

[felix . winkelmann]

> On Thu, Jul 06, 2023 at 09:05:03PM +0200, felix.winkelmann@bevuta.com wrote:
> > > This would be problematic if the finalizer has run and deleted the
> > > foreign object, while there are still weak references that hold onto
> > > the object.  This has then become invalid/inconsistent.
> >
> > I don't understand this, I'm afraid. Finalizers can always "revive"
> > objects, this can't be avoided and may sometimes even be required.
> > If weak refs suddenly make our memory model unsound, then the whole idea
> > of weak references stands to discussion.
>
> I don't think they make the memory model unsound per say.  But it is
> an issue, and one avoided by MIT Scheme by simply making it impossible
> to revive collected objects.  This thread made me consider what to do
> with such weak references and I decided that we should clear references
> to finalizable (which may already be finalized) objects.
>
> Attached is a patch to ensure that "live" weak references don't hold
> onto objects that may have been processed by a finalizer.  I think this
> removes the worst potential use-after-free footguns.
>

I'm not very comfortable with this change. This feels like trading in
one inconsistency (weak refs being cleared for a potentially non-dead
object) for another (potentially inconsistent ties of GC-controlled
memory to non-GC'd resources). Weak pairs and finalization already
undermine the strict regime that automatic memory management normally
provides, both intended to give the user more control, effectively
allowing "manual" management of external resources or limiting the
"liveness" of an object.

The potential use-after-free scenario can still happen if the object is
kept alive, regardless of how we handle weak refs, this is unavoidable
if we allow finalizers and keep the possibility of resurrection.

Clearing weak refs to objects that may not be dead after all seems to
me as the more confusing behaviour, an intendedly kept inconsistency
the user has no way to avoid without truly letting go of the object.


cheers
felix