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 15:26:01 +0000 Message-ID: <877c7aha9n.fsf@protonmail.com> References: <87jzbbke6u.fsf@protonmail.com> <86sepzf4h3.fsf@gnu.org> <87a5c6j0qn.fsf@protonmail.com> <86jzbad735.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="17245"; mail-complaints-to="usenet@ciao.gmane.io" Cc: gerd.moellmann@gmail.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 16:35:25 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 1tU6BR-0004IZ-7N for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jan 2025 16:35:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tU6B9-0001Na-D6; Sat, 04 Jan 2025 10:35:07 -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 1tU6B6-0001N1-Ft for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 10:35: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 1tU6B6-0007Bw-7r for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 10:35: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=m7ywtu6hOkQWDbb03UgcMYqMqzjexjfUMtL8bnz9nA4=; b=jvk4VDOKDe6wI45O1kc8a5z8ESjPh9qg7lTCjs8K3KDIS0UQ1Ttg6GKt7vkpA/77rtVO4nVw5fX9gJqn6SQ+uWlQpIYFuuvTFtQyNaBJgbpn3x+5shm4g5PZwgY/8O3ud3VMMfc+EnqOqsk9USlz7iSUw5pz963JpJKhf4bkoHpQbqoCOsnLtgU0AgyydItmskp5kp1a/VeHVyRZhHOgnjGYHqjmeWFMFRukK/dcyQ8T0c0aVCZ2kCOO+o58Pm3bkZrBMwbLrRGskdU5rptaVJ763rGGhfWllzMvV8v5AAv0Amx0FXbH5YxZ72PLPuclr/d4F9bGUJFsgpuDD0Ntrw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tU6B5-0006Xn-KY for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 10:35:04 -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 15:35:03 +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.173600487225102 (code B ref 75322); Sat, 04 Jan 2025 15:35:03 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 15:34:32 +0000 Original-Received: from localhost ([127.0.0.1]:56726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tU6AZ-0006Wn-Fb for submit@debbugs.gnu.org; Sat, 04 Jan 2025 10:34:32 -0500 Original-Received: from mail-106110.protonmail.ch ([79.135.106.110]:58757) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tU6AU-0006WI-81 for 75322@debbugs.gnu.org; Sat, 04 Jan 2025 10:34:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736004366; x=1736263566; bh=m7ywtu6hOkQWDbb03UgcMYqMqzjexjfUMtL8bnz9nA4=; 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=WkQ6pW4e+GpgE6lzL74gP3NKRsSEBCBSc4vcFiWPbaL3qejTFsasbPFwsuNsQphv7 203/K4Qn+HLTXtLn9XcL2mebM8pzu77m3OOwjFyB1edQawFAivpd/2qndeecbnuorp kUAayNQTvJbFy0bN9FTtjljsHtU1ZDGaleCooXI9QWH0iJiqD/lJWl+fsi61y6Gc/v 4WD+q/4+3q09Whyd8T+JL957LJNFnZjOWF5+9xsrWnnzCvxQQt5vSI3Lqnv82Rktyf kl4TMH33YyYtHtHpJ3O45TdkoSQHbxzdmvBK4hWZn6dbfFs3DeXD6xQc5ckH0+L/rz L/dR1WF9uSGPA== In-Reply-To: <86jzbad735.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: be12c40dfc8ecf252b70a813a8df39329bfda6e8 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:298422 Archived-At: "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