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 11:21:17 +0000 Message-ID: <87a5c5cxso.fsf@protonmail.com> References: <87jzbbke6u.fsf@protonmail.com> <865xmtaeh9.fsf@gnu.org> <86r05h8s9d.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="35939"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Paul Eggert , 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 12:22:28 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 1tUOiC-0009Bn-Kl for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jan 2025 12:22:28 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUOhq-0000lL-02; Sun, 05 Jan 2025 06:22:06 -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 1tUOhn-0000l7-Cx for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 06:22:04 -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 1tUOhm-0002Ps-Sj for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 06:22: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=ocjUZHWk25PwxCC/JThgUSMXihaM8Q3x4QkWimOgikg=; b=JvhxXOxtwidmlMB2gAYgkXT1aX7rTZsNGWjg0EarE30nA9J6tIGJSQOo2DAYdWzryZ7SvNvtKhAGd5Ezt4CylkzLYQV/3mSfVQOg/MHELX5tnNhBebOLU6SGKHEWTTBUcnRy659MxnLVuw8ZdR9mAObpv/vRtr/AXqppywCk9DNzRSkrVq+RscE4J3uAHZuVvxCk2rLimAyNJe+++8MNTvFqdO1/0wtNY2RJQStmRanHoctPK7dpwLMmeCO98XhAYBjk2S1CilLfUh++EnDWW1MOTYGkymnSKAGxVjPeK1yOTmEz9/vUmBp9xj2sBoqvxYYpT9kMVQ6tXI+PMg8uFA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUOhm-0004dD-GD for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 06:22: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 11:22: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.173607608917735 (code B ref 75322); Sun, 05 Jan 2025 11:22:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 11:21:29 +0000 Original-Received: from localhost ([127.0.0.1]:60131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUOhE-0004bz-N6 for submit@debbugs.gnu.org; Sun, 05 Jan 2025 06:21:29 -0500 Original-Received: from mail-4316.protonmail.ch ([185.70.43.16]:43451) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUOhC-0004bg-KL for 75322@debbugs.gnu.org; Sun, 05 Jan 2025 06:21:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736076080; x=1736335280; bh=ocjUZHWk25PwxCC/JThgUSMXihaM8Q3x4QkWimOgikg=; 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=gsipMHP8vnF5JXWd9y5QgLnqgiCm5E+3cen2XEy4xc5XUfQF1Fitrg6JSl2qz8oXI Ud9ItIc8RizleS8mAXTkqqntjiZfSAVOwCCQTCJu3dTCcGUucrOU12thKpee+h8b10 gDywSw90LowLsefGlLWbHIZTrYkKXzl4VgJex39de97Zmta6WghJ2luzPHv6chu9EJ lNW9fHl9flwHOdTwGOllFcMhuBFaPfqq0K/25gI1CequTZWaiJhpzp663HX1HPj8QW FlIK1UgwprdqS8Zc1b4nqqMC9ePjWuSC+t3otFjuN86/1i+34ymBgxcXI/zX3knOW+ DMJbL6aiWPM+Q== In-Reply-To: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 796f9c242dcf6e90652f80dc516208f2acfee41e 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:298538 Archived-At: Gerd M=C3=B6llmann writes: > Eli Zaretskii writes: >> MAX_ALLOCA is only 16KB (and Paul Eggert says it's dangerous to make >> it significantly larger), so I'm not sure your assumption about >> negligible performance impact is necessarily correct. > > Works well for me so far. Paul, this discussion is about changing SAFE_ALLOCA so its memory area is scanned conservatively for the scratch/igc branch, even if xmalloc is used (when there isn't enough stack space). MPS requires this in some cases where the old GC didn't, because it's enough for the old GC that we know there is a reference to retained objects elsewhere, but MPS might move the data in that case. However, given how rare it is for SAFE_ALLOCA to use xmalloc, maybe it would be a good idea to make the corresponding change for the old GC, too? Also, scratch/igc behaves differently with regard to SDATA: references to string data will keep the string data (but not its metadata) alive. If scratch/igc is ever merged and people start using it exclusively, we may start seeing bugs that rely on this additional safety guarantee. My preference would be to change the traditional GC to also ensure code like char *p =3D SDATA (string); string =3D Qnil; garbage_collect (); puts (p); is safe. Some memory and performance cost, but no-GC assumptions are hard to verify. This may or may not fix bugs in the present code. A potential example for such a bug is this: I think that it's possible for call_process to call Lisp via ENCODE_FILE in a very unusual scenario, which might trigger GC and relocation of string data which has already been put in the argv and environment arrays. However, I don't fully understand which additional protections traditional GC offers: is it always unsafe to use an SDATA obtained before a GC run after the GC run completes, or is there a more complicated set of rules? Pip