From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Date: Sun, 05 Jan 2025 09:47:06 +0000 Message-ID: <87ttadd25l.fsf@protonmail.com> References: <87jzbbke6u.fsf@protonmail.com> <877c7aha9n.fsf@protonmail.com> <86y0zqbgot.fsf@gnu.org> <87ttaee5qp.fsf@protonmail.com> <86a5c6b9sb.fsf@gnu.org> <87ikque0xp.fsf@protonmail.com> <864j2dacuz.fsf@gnu.org> <877c79eipq.fsf@protonmail.com> <86ttad8v37.fsf@gnu.org> Reply-To: Pip Cet Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32437"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 75322@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 05 10:48:19 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 1tUNF4-0008Km-MG for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jan 2025 10:48:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUNEq-0002rU-F4; Sun, 05 Jan 2025 04:48:04 -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 1tUNEp-0002rJ-4e for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 04:48: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 1tUNEo-00006c-Sg for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 04:48: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=jrHcG/wcUxkQdGerUmpgiFSNW5QYBuSaEvukVhqpIBU=; b=NDbIyBAiG544tVkPjZfg9Uhu3rz6AXAgfc+EH1kD1LQlVWTjU6TohSLGputwWty3LuPY5Cp4I0/MlItylCnWbKMbSiSNWnOCM/cRk9SnzlDE95M7S45CfeH083il67qUqIeqqpGdbRilP1XBMNdDNcaX2JdNl5Qq7YvIcPZNJ9YbcWVd8RyYCvMqZze8u77MwiTiP/L9Vv6XI61RMy8Gc7D1G9O/zsGkVYMLJ2BWlVzCPSMPK1QrHZ8/kIB19pmhld+FAd+NtAVvJ5VioGqNkyIH2RvenkHGGYM64XljY9CNKtvl9tpphK0mz7aEbDYpx9YN8LNwJaG/w99hHUNHHQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUNEo-0008AF-Fk for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 04:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 05 Jan 2025 09:48: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.173607044031284 (code B ref 75322); Sun, 05 Jan 2025 09:48:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 09:47:20 +0000 Original-Received: from localhost ([127.0.0.1]:59914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUNE7-00088W-IY for submit@debbugs.gnu.org; Sun, 05 Jan 2025 04:47:19 -0500 Original-Received: from mail-40134.protonmail.ch ([185.70.40.134]:63639) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUNE5-00088H-Hg for 75322@debbugs.gnu.org; Sun, 05 Jan 2025 04:47:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736070430; x=1736329630; bh=jrHcG/wcUxkQdGerUmpgiFSNW5QYBuSaEvukVhqpIBU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=R4pXmKVebESIJkGB5aDflohBtZMxVG8hdHD+l5mTT+e73vS5BtwUtYDuzx5TSLKGi JGXe0K8QYL3A2zZ7ryA2/cMiqsvkGZqTXwkYJKbff6fTNIrWy18+IdopQxXliHd7UV 8IEb9DYdYFThRNQfO3xoS1ekXaphVu2Rw2lgQ1ifT8/AJgCYWZbdCUeI8PDpgm9qCt nS2KtBEG8FJUAKcgctp72NDirsR4kDTEPhfSqgyXL0S1v5WuY7KyUtN0Ojb5ls4Zpq bpT7z8xPp1eFHhS4Ak9HD9PHSefGHKTBvXia4iQxNGTiSxZZxwi9PFUCtk64yCollG A/keRqq7WgxhA== In-Reply-To: <86ttad8v37.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 802987a871a13f48a1df15e6a437d5094c70fcf4 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:298525 Archived-At: "Eli Zaretskii" writes: >> >> >> > The below is indeed unsafe: >> >> >> > >> >> >> > char *p =3D SDATA (unmarked); >> >> >> > ... trigger GC here ... >> >> >> > puts (p); >> >> >> >> >> >> Right now, that's safe for MPS, but not for the old GC, correct? >> >> > >> >> > If GC moves string data, then it is not safe, period. Does MPS mov= e >> >> > string data? >> >> >> >> MPS does not move string data if there is a stack variable pointing t= o >> >> it. It does in other cases. This is why it's safe for MPS. The old >> >> GC, IIUC, is less forgiving. >> > >> > The conclusion is that the above is NOT safe, because in some cases >> > the data could move. Which was what I said from the get-go. >> >> The conclusion is incorrect. The code is safe if MPS is in use, and we >> rely on that. > > No, we do NOT, and should NOT, rely on that! We do, we should, and we will continue doing so. > Because you yourself say above that MPS will move the string data in > some cases. Not in this case! >> The idea behind MPS is that you write code as above, which is safe when >> MPS is in use, rather than attempting to avoid GC, which is fragile at >> best (see call_process) and impossible in multi-threaded systems. > > I don't suggest to avoid GC. I suggest that where GC _can_ happen, we > must reinitialize the pointer to string data after GC. That suggestion is incorrect. MPS GC can and does happen while we have SDATA pointers on the stack, and we rely on it to keep those valid. We need not reinitialize anything after MPS GC, and we can't do so because we don't know when and how we are interrupted for MPS GC. IOW, MPS treats SDATA point the same way it treats Lisp_Objects. That isn't the problem here. The problem is that like Lisp_Objects, SDATA pointers cannot be moved to xmalloc'd memory and retain their validity. As long as you think MPS requires us to avoid GC in this case (this is implied by "we must do this or that after GC"), your understanding of how scratch/igc uses MPS is fundamentally incorrect. Pip