From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jonas Hahnfeld via "Developers list for Guile, the GNU extensibility library" Newsgroups: gmane.lisp.guile.devel Subject: Re: GC + Java finalization Date: Fri, 19 Nov 2021 14:53:09 +0100 Message-ID: References: <9ce77d5e08d50456eddc575179b68ac17afc9bf6.camel@hahnjo.de> <1cc3648e5196bf23023ec7a0ab95a9ad46f8554c.camel@telenet.be> <21fe294b75b001afbd1be0e972a19ddb7187e98b.camel@hahnjo.de> <43a9f555dec7ddeee1ad34c278042a6bad6c59ec.camel@telenet.be> Reply-To: Jonas Hahnfeld Mime-Version: 1.0 Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="=-dp4kiHUgcSBfdqJJYvn0" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30522"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.42.1 To: Maxime Devos , guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Fri Nov 19 15:04:32 2021 Return-path: Envelope-to: guile-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mo4VE-0007l3-0p for guile-devel@m.gmane-mx.org; Fri, 19 Nov 2021 15:04:32 +0100 Original-Received: from localhost ([::1]:56318 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mo4VD-0001RV-0C for guile-devel@m.gmane-mx.org; Fri, 19 Nov 2021 09:04:31 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:33318) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mo4KN-0001QX-VO for guile-devel@gnu.org; Fri, 19 Nov 2021 08:53:22 -0500 Original-Received: from [2a03:4000:2a:2c1::1] (port=52194 helo=mail.hahnjo.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mo4KI-0001St-TR for guile-devel@gnu.org; Fri, 19 Nov 2021 08:53:19 -0500 Original-Received: from [IPv6:2001:16b8:1e92:200:6657:51b0:48f8:9366] (unknown [IPv6:2001:16b8:1e92:200:6657:51b0:48f8:9366]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.hahnjo.de (Postfix) with ESMTPSA id 671655428C3B; Fri, 19 Nov 2021 14:53:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hahnjo.de; s=default; t=1637329992; bh=hYc5ZOvyQLjUrU6NHK0Fw/jLGzQasEEMH8X5kReWALo=; h=Subject:From:To:Date:In-Reply-To:References; b=hc89+i5aN9XKGNKQn2wdDcvjSEGkn8PvyK82kuNvCQYTM6RHnReQYSLvh5B+6qAO6 Rlmv8o3yOe4fB9nw9RCnHgXgggEr3Ar+BSTpun9VwDsh6rXMJ03H7ChfRMGKbRRX1M g5C3YDYslpZY7KVtRpzm3fbPJng+uchMeVAbbeHMcK9ED9dkFH0yTZ55IdMUF/1DIa UDDaupbE8AG/yycOgcEBgngSZWR8GdXoHzGr3vjvhplTo3tZJpKXMfqzbQRYKOF4W9 GtQNHGvQWmDwTJRhg3JHYLOUhFQcgMPlzvQv3ADqt8vynjk13m0OXDF34Z2AHR5q/1 xniDqk7Ba1CrA== In-Reply-To: <43a9f555dec7ddeee1ad34c278042a6bad6c59ec.camel@telenet.be> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a03:4000:2a:2c1::1 (failed) Received-SPF: pass client-ip=2a03:4000:2a:2c1::1; envelope-from=hahnjo@hahnjo.de; helo=mail.hahnjo.de X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane-mx.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.io gmane.lisp.guile.devel:20966 Archived-At: --=-dp4kiHUgcSBfdqJJYvn0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 ... > > > > >=20 > > > > >=20 > > > > > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 scm_gc_free (rx, sizeof(regex_t= ), "regex"); > > > > > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 free (rx); > > > > >=20 > > > > > drop the scm_gc_free AFAIK. > > > >=20 > > > > 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. > > >=20 > > > The suggestion was to remove scm_gc_free, and not introduce free. > > > I.e., don't free rx manually at all, let boehmgc decide: > > >=20 > > > =C2=A0regex_free (SCM obj) > > > =C2=A0{ > > > =C2=A0=C2=A0 regfree (SCM_RGX (obj)); > > > -=C2=A0 scm_gc_free (SCM_RGX (obj), sizeof(regex_t), "regex"); > > > =C2=A0 =C2=A0return 0; > > > =C2=A0} > >=20 > > This is dangerous because we still pass the memory to regfree, so it > > must not be freed before. >=20 > 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 --=-dp4kiHUgcSBfdqJJYvn0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEXw/5YGpL6H9VOgO2kcnDPSxhrNsFAmGXrEUACgkQkcnDPSxh rNty1Af/Uddwu5SN2y3jALEgDpCGUfdVZJORO+R3SfGb/qQQHkVGZHFtLiwvFD3l wmgn+iFOnQoEuLmPWdRIB6lKKZgSB2Hb1cWoKOdD1twr7bZDSJv/yco10RSUI8g+ IwcXZGdWPsJeKt7FowHbl06D0LTkRDTybNZ+JDKB2fOBjhFxxcalscs9Quw6drIS HqAIUtkFe9oF+t/gdEQubhtKlv4s2H+XgXULUOYPLcKyiRvwnWLGJF+Q+N2M4wSt 4orvxSafi2bgCzB3560N6rVa02CoOjuYXr8/zC33EiC1C+MvcubSpLBEB+zrfGWC btz5N29n2Uem3OlS8Wg35VepkHuvfg== =Eul5 -----END PGP SIGNATURE----- --=-dp4kiHUgcSBfdqJJYvn0--