Re: GC + Java finalization

[Maxime Devos <maximedevos@telenet.be>]

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.

Greetings,
Maxime