From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Newsgroups: gmane.emacs.bugs Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Date: Sat, 04 Jan 2025 16:34:15 +0100 Message-ID: References: <87jzbbke6u.fsf@protonmail.com> <86sepzf4h3.fsf@gnu.org> <87a5c6j0qn.fsf@protonmail.com> <86jzbad735.fsf@gnu.org> <877c7aha9n.fsf@protonmail.com> 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="16553"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 75322@debbugs.gnu.org To: Pip Cet Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 04 16:35:16 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 1tU6BI-000486-3P for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jan 2025 16:35:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tU6B6-0001N2-US; Sat, 04 Jan 2025 10:35: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 1tU6B5-0001Ms-Uv for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 10:35: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 1tU6B5-00075U-8P for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 10:35:03 -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:Date:References:In-Reply-To:From:To:Subject; bh=1vYrkTMrkVjh3O/9ZH+HsFQEN0Xl6Db95Y5M3Gb2zXA=; b=ualaVryRy7ltm3wOXuygNl4GuJ9x9VyrhgLodikja6fy5zxEgMAsk5nSDDdzk8vB+oDSCUP4QBXUtqR+GlaMVIznLrUFmWujuAprkWfkyUxr1RRyXJPv1q6vC8H6buyvhP1XcbkPqrDJkf+ZP1Lelhugi9yBEdLXmkxvholUPZh/qejqhxv2sp+WgLIzExDqK8sjAszM1v5ssRW4ocDX/U0VmGb+eLwEjSt5vm3kbpVBDAKsXOhmOBHW9iiwlFHZZP7dLtokvi5pIppQkK/Fd4EKtotOkrT1FLraJd5LgqT3AYmW25ckAPa+yqSEt9D4By56U0rGC7DNSLOrPq3JbA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tU6B4-0006Xf-LS for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 10:35:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Jan 2025 15:35: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.173600486825092 (code B ref 75322); Sat, 04 Jan 2025 15:35:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 15:34:28 +0000 Original-Received: from localhost ([127.0.0.1]:56724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tU6AV-0006Wd-Rt for submit@debbugs.gnu.org; Sat, 04 Jan 2025 10:34:28 -0500 Original-Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:48359) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tU6AS-0006WG-1y for 75322@debbugs.gnu.org; Sat, 04 Jan 2025 10:34:26 -0500 Original-Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-43625c4a50dso89465185e9.0 for <75322@debbugs.gnu.org>; Sat, 04 Jan 2025 07:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736004857; x=1736609657; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1vYrkTMrkVjh3O/9ZH+HsFQEN0Xl6Db95Y5M3Gb2zXA=; b=FERooB5XpKZC9VrVcQhLPcGsm33uB7c8McHinzeDqSG5BVZJc4dguiX00zvAmyw4Gu 853vMvHp+TGQZuQ7OXI/g1dQBm2wybrzeJFIkXabNv+RfyGK2IyEeZpqvFr4Em2+ouNp jvlOp15GA8TTb4tRxDEHsR+dCe1Ru747CJAEHwZhtKCIf92pdF9XLvPX1ctTeaGg4+2T NbFoXxsphWmZbpxBcXZ/25an7xw8B+eKRevQT3l0Y+ILEnMCCYhnJfrZphCS4U20ALdk tWe5RkW4YTeYQxztTIIF5nHXLTeyLYhAmuq0NsiRy/8LCOp8KB+yZRfcaGBpVXabpkgs /cWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736004857; x=1736609657; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=1vYrkTMrkVjh3O/9ZH+HsFQEN0Xl6Db95Y5M3Gb2zXA=; b=cCDd03x6CfDCuSnzo+PHQ2AaU7diN3NAMGLleINmTB2KA5O4vgDFWqqaFPHlChtN/8 aI56wwWvMlguGVAyzhGAKeh0NF+kE+DgGNur2gY944nYYyaSj754Y7WT39T9DI8IWa1s 5PAh/8G33k6bXV62weJlKRGoZ7wUEfpw0dC9nbB008Ilawnc/VbXtZD/cJZ0oaH8cbAP 6mQRyVM+D8ic5+Fnoj++bUKDXZsnOJYc7RI65pf3qLyx3uNcTLss3lAeJlo6vUrPrvRT X7sSW10ZoMORJ1DzlcijXEdBNMQ9nP7JaxKEwAudQMxG3tHOMeSETMW1w7oUxhgL70yw 9z8g== X-Forwarded-Encrypted: i=1; AJvYcCWnPx5r2Vh1O8fU7nUWYP8842iFFcbyUJkvDmMHodw/Nqd0fK0MSpS0ACd4lqKQUn2QNNb5lw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwVo+BUNNn2doWyiYFLY4GmcdD56dMAUk+Q+Mbf+jDNFZVQ5fhI Ke5o+8sR5UKJGwmtPmDikwds50/Ib20W8uYIvfDJ7wjO8UJKlgZBEqhfvg== X-Gm-Gg: ASbGnct/vG3fhhLgOeLz0CIVXjYEwn8BllRT9HfpIwHTBz9RB2Y4G8GetpGt9t3NlU+ /JKvywwvUJxhUE9cLbe30KId68khG4j1derI8VKMyFEypvBmo1yboxEDi8d63Zg6o0nlx5sGtAt HqecWjGVPBPYkwPIpvKssiq3epL7DonMi2te7sMNNmN7sosT9R85EDWW9fdhLcaD1ZF0o/BXB4z AMw99hTfA21+Q6k2wB/ThKri9RMpntLt72EwEoKCeq/+AJGgdmrM8qkOc1OVuersveM7gSJ/SwX xRbnce0Cf+eEYPJQpUQ5USEFS2acXdrHpZgHRCf67Ouii63X/10nK5ZMZpA7zVd6Og== X-Google-Smtp-Source: AGHT+IHYozgRMp3IXSWqokIgW/gJcsfVcEi2hjs5m843ogSusSQBhwfrcuduB7OgxLXzCwfc4/SCIA== X-Received: by 2002:a05:600c:5246:b0:42c:bb96:340e with SMTP id 5b1f17b1804b1-43668b7857amr487638765e9.31.1736004856957; Sat, 04 Jan 2025 07:34:16 -0800 (PST) Original-Received: from pro2 (p200300e0b73c9f00c50ae305bf989514.dip0.t-ipconnect.de. [2003:e0:b73c:9f00:c50a:e305:bf98:9514]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43656b3b271sm546893305e9.34.2025.01.04.07.34.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jan 2025 07:34:16 -0800 (PST) In-Reply-To: <877c7aha9n.fsf@protonmail.com> (Pip Cet's message of "Sat, 04 Jan 2025 15:26:01 +0000") 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:298421 Archived-At: Pip Cet writes: > "Eli Zaretskii" writes: > >>> Date: Sat, 04 Jan 2025 11:08:50 +0000 >>> From: Pip Cet >>> Cc: Gerd M=C3=B6llmann , 75322@debbugs.gnu.org >>> >>> "Eli Zaretskii" writes: >>> >>> > The current code in callproc.c assumes that GC cannot run while we are >>> > parked in posix_spawn or vfork. >>> >>> If you're attempting to explain why the current code is safe (if you're >>> saying it is), it assumes much more than that. call_process assumes >>> Fexpand_file_name doesn't GC, for example, which seems unsafe to me: the >>> function calls Lisp, which may do anything, including modifying >>> Vprocess_environment. >> >> AFAICT, expand-file-name is called before we start using the SSDATA of >> strings in the args[] array. Or what did I miss? > > You're right, thanks. I got confused between args and new_argv. > > The next thing I'd look at is the final call to ENCODE_FILE, called > after new_argv is set up; this ends up in encode_coding_object, which > calls safe_funcall in what seems to me to be an unlikely but possible > code path. I assume that's unsafe (the safe_ refers to redisplay, not > GC, IIUC)? > > While maybe_quit is "safe" because it inhibits GC, I believe it can > still call the debugger, which might require more memory than is > available until GC is re-enabled. > >>> Regardless of what you're saying, such assumptions need to be spelled >>> out. Where they are made, that is, not in a utility function. >> >> I'm okay with spelling out these assumptions. > > Excellent. Now we just need to establish what they are :-) > >>> Yes, make_environment_block does say its callers can't run GC, but >>> call_process doesn't indicate when and how it establishes a no-GC >>> assumption. >> >> What would be needed to indicate that? > > I'd prefer a pair of macros (no-ops in regular builds) to comments, but > there is no obvious best solution here. > > My proposal would be to remove most (ideally, all, and then we're done) > no-GC assumptions, and put the few ones that must remain into separate > function bodies for the no-GC / possible-GC cases. Then we can put the > no-GC function bodies into a separate section and prohibit references > from no-GC to possible-GC functions, and have the linker check that. > >>> > Is that assumption false with MPS? >>> >>> As we agreed, code should be written to assume GC can strike at any >>> time. >> >> I don't think we agreed to that. At least I didn't, not in this >> general form. It would be a huge job to make all of our code comply >> with this. > > I said "That's what you should think: GC can strike at any time", and > you said "The same is true with the old GC". I misread that as > agreement. > >>> IIUC, Gerd explained that the old GC can still move the string *data* >>> used in that structure, even if the string metadata stays in place. >> >> If string data is moved, then accessing the old pointer would trigger >> the barrier and MPS will do its thing, not? > > Sorry, but I think I'm confused here. > > IIUC, MPS doesn't currently use barriers on data that is moved (it > could, so the data is copied lazily, but I don't think that's what you > meant), it uses barriers on data that contains references that may not > have been fixed. > > If a pointer to "old" data is ever exposed to Emacs, we lose, because > MPS will reuse the memory for new data, which might be behind a barrier. > > If we ever do: > > static Lisp_Object unmarked; > unmarked =3D string; > ... trigger GC here ... > puts (SDATA (unmarked); > > the most likely outcome (thanks to Gerd for the hint) is that > nonsensical data is printed, because the string data was reused for > another string; less likely, but possibly, the data is reused for a > different pool (with barriers) and we'd get a SIGSEGV; even less likely, > puts() will call write() directly and we get an EFAULT, and glibc does > whatever glibc does in that case (set errno, I hope). > > Accessing the old pointer is never okay. MPS can't fix it, and doesn't > make catching such errors easy. > >> To clarify, I was trying to understand whether the error message >> reported by Ihor in another thread could have happened because of GC >> in this are of the code. > > I currently think that Ihor's test case calls execve () with nonsensical > "environment" strings a lot, and once in a while they'll even be behind > the barrier which causes an EFAULT. GNU/Linux seems relatively > forgiving about strings without "=3D" in the envp, for whatever reason. > > Pip I'm entering a state of confusion again, as usual in this discussion. Can we _pretty please_ just do the xstrdup thing, and forget about it?