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: Sat, 04 Jan 2025 11:08:50 +0000 Message-ID: <87a5c6j0qn.fsf@protonmail.com> References: <87jzbbke6u.fsf@protonmail.com> <86sepzf4h3.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="29022"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Gerd =?UTF-8?Q?M=C3=B6llmann?= , 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 12:10:32 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 1tU235-0007QV-Ni for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jan 2025 12:10:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tU22f-0005Fn-0d; Sat, 04 Jan 2025 06:10: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 1tU22d-0005FO-46 for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 06:10: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 1tU22c-0006kD-Rm for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 06:10: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=mkV36oRdn43Zz9KrOQLtx+h1jjqNywwgq5tcn9Bf1Mg=; b=vXAbE4IRrGQfnDWggp1IvpyodUIcrjxWi0AyKO3/ssL9XtwEXbUvPiBzQLAlmRK/JJ5vxkc8sD3xWUwADPCNeS8MfkpoSHAYwqdFBGKmDQpbQAPIfggsDCJx0Egq46Jq18rqeYCep3fVUJp4ZJ+R7MFJSbz2tPNMTmZ32g/XitBvIpznPskSsh0+ur5ZuWqYIEsTSxg+TNSuL5W+Z2bI0bFzeaMa5jdBI3C6aanMtJ9IXEWgzrBo4eJ/SAHyyyED0a206KhZEoYrjf/5w7ch5V40vgwZplLyQfZXRxnV7uIfnIfZsxlLZKZaqhOPLhKoGtqOe7zgH9jNyN/liGQH1g==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tU22c-0001Sm-KZ for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 06:10: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: Sat, 04 Jan 2025 11:10: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.17359889475557 (code B ref 75322); Sat, 04 Jan 2025 11:10:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 11:09:07 +0000 Original-Received: from localhost ([127.0.0.1]:53529 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tU21i-0001RZ-HG for submit@debbugs.gnu.org; Sat, 04 Jan 2025 06:09:06 -0500 Original-Received: from mail-10631.protonmail.ch ([79.135.106.31]:46177) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tU21g-0001R1-4e for 75322@debbugs.gnu.org; Sat, 04 Jan 2025 06:09:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735988936; x=1736248136; bh=mkV36oRdn43Zz9KrOQLtx+h1jjqNywwgq5tcn9Bf1Mg=; 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=CwxKVa4FGpq1qVcoF5w8tU5eCZep/chMvdjkE3p/HX1ZB2szEHm37a/DdKwmfjFVh OnW3xjtcss1KZ4oRIvczJl4L0nGj5gQETr0Wjd1s5pQP8fd9U9hCPEJK0zJ4uL1Ptm zU0j8FTBTLVN7TS05zMGPxbqvln/SbdiaFd3HI2ExffMq+MxSGoxgTtGRnHri3bI+/ yz2WYW3ws1Co10UrPmINCojy2KZI8u1vEDdgZSKz4tmQFzU7GWM6/Wo8ZyuiKDVQmW DnM2zqCI4KjDzhhlPkZPiPNNPZWGuMvSgI93I90qkMTXpM7ZwuH3PQbQTuvyz0P6Vk KFOoVKS9CbHgQ== In-Reply-To: <86sepzf4h3.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 10ba730b7ccf6fb9fc34e2fbe2773ac79190ade7 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:298357 Archived-At: "Eli Zaretskii" writes: >> Cc: 75322@debbugs.gnu.org >> From: Gerd M=C3=B6llmann >> Date: Fri, 03 Jan 2025 21:34:07 +0100 >> >> Gerd M=C3=B6llmann writes: >> >> > >> > The pointers to string data case probably requires adding yet another >> > macro SAFE_ALLOCA_FIND_A_GOOD_NAME, which, for MPS, allocates a root, >> > possibly and exact one which would be good. >> >> Or one does it as you did in b0a209e9204, that's of course also safe. >> For both old and new GC. (Don't remember if you mentioned it Pip, but >> old GC moves string data as well, during string compaction, should GC >> run). > > 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. Regardless of what you're saying, such assumptions need to be spelled out. Where they are made, that is, not in a utility function. 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. > Is that assumption false with MPS? As we agreed, code should be written to assume GC can strike at any time. In the context of MPS, to make things more difficult, "GC can strike" may mean a full GC happens (moving objects) or a memory barrier is lifted. > 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? It's a global variable. Those are 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. 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. Pip