From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Date: Sun, 05 Jan 2025 19:45:43 +0200 Message-ID: <86msg56to8.fsf@gnu.org> References: <87jzbbke6u.fsf@protonmail.com> <87msg7iq0o.fsf@protonmail.com> <86ed1jf1tp.fsf@gnu.org> <865xmugawr.fsf@gnu.org> <8634hx8k1u.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10890"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 05 18:46:23 2025 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1tUUhj-0002hS-Lq for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jan 2025 18:46:23 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUUhQ-0006lC-S7; Sun, 05 Jan 2025 12:46:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUUhP-0006l2-3E for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 12:46:03 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tUUhO-0004BW-QZ for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 12:46:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-version:References:In-Reply-To:From:Date:To:Subject; bh=pbMYh7S4SD6pzyYvjUWUV8aomKiMu4k/JXmEseiD7h8=; b=Xg5hjYD3b4YFvharcTQaZabWAgynj+4t04P3lirSIHrhEzHn8slBCy7mPcJ6dwdhH30fWJ8Y+BfdMU5ZPnZbCGA0JrI7KpaMl7oUQSMh3dxfbtzGhQgeTIkSO/qS1HvpHJQhRrFvAWKDUVcyAZ/nb2WUNWKkjGixsZ4+oRTiy5m7NmXVUVfvMbMlG+U5WcYBD5bqzVGEDf6u9J5jR9cee6sLFnBUwL5/3e+F9yJXwqmbM5amMwW9aAiwo7QuKvDK8nK3XTLTu+wrRh/gsPbWLf4XusT2JsS6qkqlrzGrympwDqlUo7mjaALC1N6yLk2heIjkrI7SICFV4plq2td5eA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUUhO-0007tx-Kr for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 12:46:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Jan 2025 17:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75322 X-GNU-PR-Package: emacs Original-Received: via spool by 75322-submit@debbugs.gnu.org id=B75322.173609915530352 (code B ref 75322); Sun, 05 Jan 2025 17:46:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 17:45:55 +0000 Original-Received: from localhost ([127.0.0.1]:35047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUUhH-0007tT-3t for submit@debbugs.gnu.org; Sun, 05 Jan 2025 12:45:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35716) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUUhF-0007tA-1w for 75322@debbugs.gnu.org; Sun, 05 Jan 2025 12:45:53 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tUUh9-0004Am-AI; Sun, 05 Jan 2025 12:45:47 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=pbMYh7S4SD6pzyYvjUWUV8aomKiMu4k/JXmEseiD7h8=; b=O0+JlhyhEl5FH9Yn6XA0 8YsERBuxna3s9m1S2ZTfe+C2lBYh+cPkf2wYv9y8BJpF95BKC6c4hpi7AM9FqlqDTvFuKf4F0mPAe XPVyKfVSJ8IlYTqF3awUlQfPxKF6GTFbmSUuG5uWjDF3ziFYgVFBwaRVdjpVDgX3MmDXU8r82Yfp+ WJ5bct8WsbWr2bsiDUVBVSYxT/OyS5WZKnBW/dFt7HUpuhpmXnZlWdhMyXbP7rNGmdz5ZWikcw2ei 8gTRTadrsBpr3Ld8LAA7lTSCZFAnrXJcOU+ak9cnNTIz+bKrLy/yHBiSsfmHjf04cti3E1uS4Goz4 SRRnc954umsVbA==; In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Sun, 05 Jan 2025 15:11:08 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:298578 Archived-At: > From: Gerd Möllmann > Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org > Date: Sun, 05 Jan 2025 15:11:08 +0100 > > Eli Zaretskii writes: > > > And if GC _can_ happen, > > but we don't use the allocated block again, is that a problem? For > > example, in this fragment: > > > > SAFE_NALLOCA (args2, 1, nargs + 1); > > args2[0] = Qcall_process; > > for (i = 0; i < nargs; i++) args2[i + 1] = args[i]; > > coding_systems = Ffind_operation_coding_system (nargs + 1, args2); > > val = CONSP (coding_systems) ? XCDR (coding_systems) : Qnil; > > > > Let's say Ffind_operation_coding_system could trigger GC. But we > > never again use the args2[] array after Ffind_operation_coding_system > > returns. Is the above still unsafe? If so, could you tell what > > could MPS do during GC to make this unsafe? > > Let me first say why I find this unsafe in the old GC, in principle. If > we don't assume anything about the objects referenced from args2, then a > reference in args2 may well be the only one to some object. In this > case, the old GC would sweep it. OK, but in most, if not all of these cases, the objects are referenced from the stack. For example, in the above fragment, the args[] array is on the stack. Right? > Not using arg2 after Ffind_operation_coding_system above is not enough. > It would have to be not using args2 after the GC has run. Maybe that's > _in_ Ffind_operation_coding_system. OK, agreed. > Additionally, objects might not die but may move, assuming that > SAFE_NALLOCA does not create an ambiguous root. So, using SAFE_NALLOCA > makes another assumption in the MPS case: that something else prevents > the objects from moving. Another proof or check required with my GCPRO > hat on. What does it mean in detail "the object may move"? A Lisp object is a tagged pointer. Do you mean the pointer should no point to a different address, i.e. the value of a Lisp object as a number should change to still be valid? And if so, is MPS supposed to find all the copies of that value everywhere in order to update them? So if I have several variables which were all assigned a value of the same Lisp object, they all need to be updated when the object moves? > > Also, in some other message you said SAFE_NALLOCA is unsafe if > > _pointers_ to Lisp objects are placed in the memory SAFE_NALLOCA > > allocates off the heap. In call_process I see that we only ever put > > Lisp objects into the memory allocated by SAFE_NALLOCA. If that is > > unsafe, could you tell what MPS does during GC which makes this > > unsafe? > > Not sure, is the question why in MPS both pointers and Lisp_Object count > as "references"? Yes, if that's the situation. Earlier you only mentioned pointers to Lisp objects, something that happens relatively rarely.