Re: GC + Java finalization

[Jonas Hahnfeld]

Am Freitag, dem 19.11.2021 um 13:44 +0000 schrieb Maxime Devos:
> Jonas Hahnfeld schreef op vr 19-11-2021 om 14:40 [+0100]:
> > Am Freitag, dem 19.11.2021 um 13:35 +0000 schrieb Maxime Devos:
> > > Jonas Hahnfeld schreef op vr 19-11-2021 om 14:32 [+0100]:
> > > > > You coud simply ...
> > > > > 
> > > > > 
> > > > > > -      scm_gc_free (rx, sizeof(regex_t), "regex");
> > > > > > +      free (rx);
> > > > > 
> > > > > drop the scm_gc_free AFAIK.
> > > > 
> > > > No, I cannot as explained in the patch summary: If we use
> > > > scm_gc_free
> > > > in a free function of a Smob, this relies on Java finalization
> > > > because
> > > > the memory must not be reclaimed in the same cycle.
> > > 
> > > The suggestion was to remove scm_gc_free, and not introduce free.
> > > I.e., don't free rx manually at all, let boehmgc decide:
> > > 
> > >  regex_free (SCM obj)
> > >  {
> > >    regfree (SCM_RGX (obj));
> > > -  scm_gc_free (SCM_RGX (obj), sizeof(regex_t), "regex");
> > >    return 0;
> > >  }
> > 
> > This is dangerous because we still pass the memory to regfree, so it
> > must not be freed before.
> 
> How can removing a call to a free function introduce new use-after-free
> bugs or double-free bugs? AFAIK, ignoring memory leak concerns (which
> don't seem to apply here because of boehmgc), freeing less stuff cannot
> introduce new bugs.

It doesn't introduce a new bug, I'm just trying to explain that there
already is a bug / an implicit dependence on Java-style finalization.
Let me try to explain my understanding how it works, and why this is
bad:

scm_make_regexp currently uses scm_gc_malloc_pointerless to allocate
memory for regex_t. The pointer is stored in a newly created smob,
whose memory is also under the control of the garbage collector. In
regex_free, the regex_t is passed to regfree, which requires that the
memory is still there and not freed yet.
This "happens to work" with Java-style finalization because the smob
points to the regex_t and so the two are not collected in one go. This
assumption breaks in the more "greedy" mode where entire chains of
unreachable objects may be collected at once. Removing scm_gc_free
"solves" the immediate crash (the GC complaining that the memory has
already been freed), but regfree still attempts to read from the
memory.
The straight-forward solution is to statically tie the lifetime of
regex_t to that of the smob. Which we cannot do with GC, but simply
with malloc+free - as implemented in the patch.

Jonas

signature.asc
Description: This is a digitally signed message part