unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: Maxime Devos <maximedevos@telenet.be>
To: Jonas Hahnfeld <hahnjo@hahnjo.de>, guile-devel@gnu.org
Subject: Re: GC + Java finalization
Date: Fri, 19 Nov 2021 13:53:02 +0000	[thread overview]
Message-ID: <bc51822cd6a6c6685cca9e57b303e1de14a33fb1.camel@telenet.be> (raw)
In-Reply-To: <43a9f555dec7ddeee1ad34c278042a6bad6c59ec.camel@telenet.be>

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.





  reply	other threads:[~2021-11-19 13:53 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-03 12:05 GC + Java finalization Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-07-03 17:14 ` Maxime Devos
2021-07-03 17:26   ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-07-03 18:49     ` Maxime Devos
2021-07-03 18:54     ` Maxime Devos
2021-07-15 18:44 ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-10-10 16:22   ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 12:18     ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2022-02-22 10:14       ` Dr. Arne Babenhauserheide
2022-02-22 15:12         ` Mike Gran
2021-11-19 13:13   ` Maxime Devos
2021-11-19 13:32     ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 13:35       ` Maxime Devos
2021-11-19 13:40         ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 13:44           ` Maxime Devos
2021-11-19 13:53             ` Maxime Devos [this message]
2021-11-19 13:53             ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 14:01               ` Maxime Devos
2021-11-19 13:48       ` Maxime Devos
2021-11-19 13:55         ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 14:14           ` Maxime Devos
2021-11-19 14:52             ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 18:48               ` Maxime Devos
2021-11-19 19:01                 ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 13:15   ` Maxime Devos
2021-11-19 13:35     ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 14:21       ` Maxime Devos
2021-11-19 15:32         ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-19 13:17   ` Maxime Devos
2021-11-19 13:38     ` Jonas Hahnfeld via Developers list for Guile, the GNU extensibility library
2021-11-20  9:19   ` Maxime Devos

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bc51822cd6a6c6685cca9e57b303e1de14a33fb1.camel@telenet.be \
    --to=maximedevos@telenet.be \
    --cc=guile-devel@gnu.org \
    --cc=hahnjo@hahnjo.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).