From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Date: Sat, 04 Jan 2025 15:47:10 +0200 Message-ID: <86jzbad735.fsf@gnu.org> References: <87jzbbke6u.fsf@protonmail.com> <86sepzf4h3.fsf@gnu.org> <87a5c6j0qn.fsf@protonmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="666"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.com, 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 14:48:33 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 1tU4W1-000AaX-1T for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jan 2025 14:48:33 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tU4Vd-0005eY-6m; Sat, 04 Jan 2025 08:48:09 -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 1tU4Vb-0005eH-2z for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 08:48:07 -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 1tU4VX-0007nU-2l for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 08:48:04 -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=jVthav1bpAOUfswzn4aCTrVlKDOm6VVCNqbzYTXFgsQ=; b=CTm+C5wAgl+c+wXq50GZmAz28oTHKy25dt21Xp1KIwZSQXjxo4GqCFxpoUkJL5B+x62Z3PkuTIVLM+GygC8hcLP+6j75dfSBL23FFDTX5nDtMClqzdXfizR08OgDyTHl47Mbm/G/UKSbWMKGefVd1GXGFpo3FhzL021fhxDL42zIvDjjbrZOa8ab43o0473Mnew5glB+bQuSScdbm7hVCFgAjejlPTVMz1Gci23fWs8f1lPxPeqiHcKwgfbr2y77oUKjv1UBcN47XZ1j80705c0PiYXbORqe8QUeMsv/3zdDggvmouNN1ko1AgzNbBA6bSaj9m76zn/i0eOIBNPNZQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tU4VW-0000YJ-MX for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 08:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Jan 2025 13: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.17359984452072 (code B ref 75322); Sat, 04 Jan 2025 13:48:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 13:47:25 +0000 Original-Received: from localhost ([127.0.0.1]:53945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tU4Uu-0000XK-0g for submit@debbugs.gnu.org; Sat, 04 Jan 2025 08:47:25 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55440) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tU4Uq-0000X5-DL for 75322@debbugs.gnu.org; Sat, 04 Jan 2025 08:47:21 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tU4Uk-0007l1-VG; Sat, 04 Jan 2025 08:47:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=jVthav1bpAOUfswzn4aCTrVlKDOm6VVCNqbzYTXFgsQ=; b=kPGDjZMYADDuroonTp7D iYIP/chqYtGeTf2Fcz1pz4AROOBWXUPA93oMAaRzB8NYslBH2XYZ/Fi/rMYFC7VzLzFSWzdICUFRk Nr8ABZTIdZYShGcgHIP80S2IIu3LounEVjk0IUXYZy6mE3roWOPcL9lCkcMymFFY7ImxzwtiNImXF Jg/mw3hPObBO8JTfzWX/EMRYoo7JuMyn0o5NcaoG7FVpox/qEQNB4x6EYiAaawFpwGFHm3fRWR7oI xafb7+jk7SfxtOm5C6b3b+O23/kWv9dGZa5vN5rDi7wZ3QPftshu5lfe4w99p+VkMpskShuR7WRuk 54fydWTXUZac8g==; In-Reply-To: <87a5c6j0qn.fsf@protonmail.com> (message from Pip Cet on Sat, 04 Jan 2025 11:08:50 +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:298401 Archived-At: > Date: Sat, 04 Jan 2025 11:08:50 +0000 > From: Pip Cet > Cc: Gerd Möllmann , 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? > 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. > 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? > > 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. > > 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. If string data is moved, then accessing the old pointer would trigger the barrier and MPS will do its thing, not? 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.