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 09:58:56 +0100 Message-ID: References: <87jzbbke6u.fsf@protonmail.com> <86sepzf4h3.fsf@gnu.org> <86cyh3f0mr.fsf@gnu.org> 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="24794"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: eller.helmut@gmail.com, pipcet@protonmail.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 Sat Jan 04 10:00:18 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 1tU014-0006Hm-6t for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jan 2025 10:00:18 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tU00s-0005tL-Bg; Sat, 04 Jan 2025 04:00: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 1tU00p-0005oT-Pt for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 04:00: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 1tU00p-0000Oq-G1 for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 04:00: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=ZVAw9WW2aVoiQKouw2L57X4aY99E2Nw8e/EHuwEJ3kY=; b=uxYvdM0rgAqHapFJfbsEsx5hR5wY6T5JsykZnn3fi8ooRYike2aVwpQOpmjOFb5mKg5mr0oKPeh1FF4c1L5bSizIGI83yvoAqDxGc6dfl6p79iiiEtmuWmgdyietq1vXbkguzMZPEYzVvMtLRmB/B+YX6wY2IOqp8EbuSxlQbi/1yUolSJKvXB4fuwsieJDuHMJzq0TMPzucPr4ElMZapA+pkDum1g1h1C0x6Rmw/QpC7dMB2Q1BVEAsYgggWc1UxK1uzBpe5IzZaTOYai9T/g/paOd5HPa+9i7QEMrR9O233BoQ+PE2JMIca8Mux+3Thx96hHBduVWd/otRy9QA9Q==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tU00o-0003vY-UR for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 04:00: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 09:00: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.173598114214993 (code B ref 75322); Sat, 04 Jan 2025 09:00:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 08:59:02 +0000 Original-Received: from localhost ([127.0.0.1]:53340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTzzp-0003tY-UX for submit@debbugs.gnu.org; Sat, 04 Jan 2025 03:59:02 -0500 Original-Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:42274) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tTzzn-0003tL-E2 for 75322@debbugs.gnu.org; Sat, 04 Jan 2025 03:59:01 -0500 Original-Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-3862b364538so7375242f8f.1 for <75322@debbugs.gnu.org>; Sat, 04 Jan 2025 00:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735981138; x=1736585938; 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=ZVAw9WW2aVoiQKouw2L57X4aY99E2Nw8e/EHuwEJ3kY=; b=JHFWXgHIL9XGhWzFunDeb4zDLcGW9JzwvxGUeKxgM8rTn47OYl2c8SPxpPFCAZ617T fnVu/HmUKo6yIVl9aWpdnXoj9PMbuBYuMENXJzzucrLMnDXDcIlxAw/lDgSrPU9256/q QyyOo9QXI+6hqtZoS/OlBhCQ/PkNsCwTK1IJcquYbE52/MVb8zrDJhivqo/BCip9nsX9 SAbnefuZ9+IQcrPWA2Q0k0KIkejQp8zMsNU9Ok02D2Ayb0kTyFUSjAGHWq+Ee2hpXrFx So+NtklS2tr9KPm1XMgh2CQPpimg1nOf4Zmk9hhIb03FBCShzt7F+zO6VJPjQ8D1zZRY iHsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735981138; x=1736585938; 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=ZVAw9WW2aVoiQKouw2L57X4aY99E2Nw8e/EHuwEJ3kY=; b=cn6m3QpZFOdoiVu6i1vPuUbqDLUmuO0RlAZni6X14NcLcMTqXn/ssAzt51Q1JBgcM/ IQLbIk+r5wiO2Msfm0vK4s7O63EliCinhv7sdNTJHbFazHWpOTHP+QyZF2wLt+mL5hle nQDcN+FOzM6xo515UNLQe6pg+WJD0FrkYU661CQicZvlFa7WKSKinG8gasTut4tnX9SQ dOdt8uiGaIYh5C5rf9FwCSLiMQNg+Hf9GquQRYcrwWLcDwlg6fB+qr6la86mGjC1y0xb NFQ8YUDkGo4x+y9Ndp0oWCeUbW8cUyog6uPeD/nMaeNGTF66ZCYchywatUc9C4l+7oPM i1iw== X-Forwarded-Encrypted: i=1; AJvYcCWRXetYwWu0M+Zu1f6quXcxdqsr7mBbibBtZsVAHnuRm9mLQ3Vv2AihoF/fItlZDHi+jpRGoA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz0zUEFyZfyuY8PT88tG0vRxd1ye/Rkb2y2AkNT6QzBArnESdMd 1Xfb+N9nqDID5+j/O/A+6xcQOSE//Z2wtz6bJz9q9uPc3j5TZXvshe1fiA== X-Gm-Gg: ASbGncsKa8s9Tj7ey4DQRySkRpCi+a9WFctV1BEA59PQNOINYM35Jrnj0antR8GejLM xv9t4g3Lp/F0NmzR2HAWrfAlMXgFaOXehWLM5JeX1UZ5LNdZk6HO3UGF0u8LeIqulGFblAmvteN /dYHgV4kxWo6V5caZGlneYJxMSsxnoS5oN9wtxYishK6Vc9v4eeaakbBTWhuKHC37PjUEGUpgc2 OPdf7OdFsXIR+xoHdWlt2XWf0sL45XRwQc/7zqkxVO425SYE0z48Cp3aaqflZ8UJhcVHnBlM45/ G+IMA34I8O8DB+6uhoGNwKjlKCrxuo8f53AZAL7mSxOQA3R9kpizjGCot3ggsZBkIA== X-Google-Smtp-Source: AGHT+IFo+asWD2Yqd4pgAo3EbJiSz/BE0wnUhxSNg2+D2GFuhtgAkA2cUR4oClHBlFzPh+HU5Wr5dQ== X-Received: by 2002:a05:6000:1faa:b0:386:3672:73e7 with SMTP id ffacd0b85a97d-38a1a1fdecfmr50086019f8f.9.1735981137701; Sat, 04 Jan 2025 00:58:57 -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-4366112e780sm504648405e9.0.2025.01.04.00.58.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jan 2025 00:58:57 -0800 (PST) In-Reply-To: <86cyh3f0mr.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 04 Jan 2025 10:23:40 +0200") 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:298345 Archived-At: Eli Zaretskii writes: >> From: Gerd M=C3=B6llmann >> Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org, Helmut Eller >> >> Date: Sat, 04 Jan 2025 08:17:34 +0100 >>=20 >> Eli Zaretskii writes: >>=20 >> > The current code in callproc.c assumes that GC cannot run while we are >> > parked in posix_spawn or vfork. Is that assumption false with MPS? >> > If so, what would trigger GC during that time? >>=20 >> Okay, so it's safe with the old GC, I assume. Do you know if it is done >> with an inhibit_garbage_collection? > > No, without. Unless posix_spawn could somehow call back to us in a > way that posix_spawn will later return and resume running (as opposed > to via a fatal signal), how could GC happen? > >> Not that we run into the trap that somewhere on the way to the >> actual fork maybe_quit is called which can GC and so on, like we had >> it in the regexp engine a while back. > > This can be established by examining the code, right? In principle yes, one could check if maybe_quit is called in the call trees between the point SDATA is stored and fork happens, but I wouldn't do it because (1) someone might add a maybe_quit at some point, (2) Pip's solution is immune to the problem, and (3) it's potentially a lot of work to figure out if GC can be called in a call tree. >> For MPS, I don't know for sure. I have seen in passing while git >> grepping in their repo recently, that they write something about forking >> and child processes, but I don't know what they do. Maybe someone having >> read the code can answer that. (Added Helmut in CC). > > We are talking about vfork, not fork. In our case, the forked process > runs a completely separate program, in most cases not even Emacs, so MPS > has no bearing on that, I think. Okay. I hope Helmut and/or Pip know more about this than I do. >> > Another question is about the global Lisp variables in 'globals'. For >> > example, Vprocess_environment actually globals.f_Vprocess_environment. >> > Is this large struct protected from GC, i.e. can GC ever decide that >> > process-environment is not used and free it? If it's protected, where >> > and how is it protected? And if it is protected, then any members of >> > the list that is the value of process-environment are also protected >> > and cannot be freed by GC. >> > >> > If 'globals' is not protected, I think we should protect it, no? >>=20 >> process-environment is a DEFVAR_LISP, and is root in both GCs via the >> staticpro mechanism (staticvec array). > > OK, so it's impossible that some member of the process-environment's > list will be GCed, right?=20=20 Right. > AFAIU, Pip was considering a situation where some of these member > strings are GCed, and then subroutines of posix_spawn use a bad > address, to explain the error message Ihor reported. This seems > impossible because process-environment is staticpro'd, right? I think that scenario cannot happen in this case, right. I'd like his xstrdups better anyway, so that all becomes irrelevant for both GCs. Less to worry about :-).