Re: GC + Java finalization

[Maxime Devos]

Maxime Devos schreef op vr 19-11-2021 om 13:44 [+0000]:
> 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.

Unless scm_gc_free is called to act as scm_remember_upto_here,
such that the memory regex_t isn't freed until regfree has done what
it should?  But regfree is called with the regex_t, so
scm_remember_upto_here wouldn't be needed.

Unless it actually is because of how finalisation in boehmgc interacts
with how boehmgc keeps track of what can be collected and what not
(I don't know the details).


Greetings,
Maxime.