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: Sun, 05 Jan 2025 15:30:37 +0200 Message-ID: <8634hx8k1u.fsf@gnu.org> References: <87jzbbke6u.fsf@protonmail.com> <87msg7iq0o.fsf@protonmail.com> <86ed1jf1tp.fsf@gnu.org> <865xmugawr.fsf@gnu.org> 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="2126"; mail-complaints-to="usenet@ciao.gmane.io" Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org To: Gerd =?UTF-8?Q?M=C3=B6llmann?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jan 05 14:31:31 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 1tUQj5-0000KJ-9O for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 05 Jan 2025 14:31:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tUQik-0005KT-4b; Sun, 05 Jan 2025 08:31:10 -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 1tUQif-0005KE-8N for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 08:31:06 -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 1tUQid-0005gl-6l for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 08:31: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=mehWfV8lJXj+1vhihGcAXxujXjHqmoOuqT6UpBtegDY=; b=Vb48rZlRRWzxv2xC5i2MQiTkgT6fo+m6kYmDV8Cvto4LV8W49JMLfQCiHreLsKsMhN5rUT5MCytjyWV4JQGeoOesIuK/BxLgcZ12iN/EoCYncL7LHPAUanCvs1n+vwO564fTXEb+9J1bDRYWU9P/n6hHvIzir9g/LaGysjh+fA8c/a3+MgHo8o/QbBdNeFez529xPgDcjVlgiL+ahwJeFv/3+1vTBBLAR/lORQsvV7hXZWbgEFnMKQPjT14f4jTx6yZlBvElCTiTzIJn0CbheDm07ck4sMDGlxCHF/4bWxlN8spH2t+Na/4cVt28cDmwXeiV3jeJ/iKDP0q3e1JwmQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tUQic-0003Db-7x for bug-gnu-emacs@gnu.org; Sun, 05 Jan 2025 08:31: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: Sun, 05 Jan 2025 13:31: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.173608385312353 (code B ref 75322); Sun, 05 Jan 2025 13:31:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 13:30:53 +0000 Original-Received: from localhost ([127.0.0.1]:60382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tUQiS-0003DB-H5 for submit@debbugs.gnu.org; Sun, 05 Jan 2025 08:30:52 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34144) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tUQiN-0003Cg-R7 for 75322@debbugs.gnu.org; Sun, 05 Jan 2025 08:30:49 -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 1tUQiH-0005fS-9H; Sun, 05 Jan 2025 08:30:41 -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=mehWfV8lJXj+1vhihGcAXxujXjHqmoOuqT6UpBtegDY=; b=Dv9XIztWqGOyqdh5k0T/ /xp5WICElf07MgF0iGJFJ/bIQN9TUAJ8qMOZYlfvNn574w9ysyFtMBWrusbMSRaoWD8oWh33Mxoi0 MovpeGf6EM8r8BpbSK+9EQhmIMUSkww1C5Qr65Lp7X+GM6qG+yQWV17TstB5gWPlJJVd2AZFh8G4k 3HbZxIRsUb10+IUQCPw0PYgS2aVoIlwG3bJlq2GVgDZaXMWndJgeviqJhh8zlbbRASZ1/BHBEY55g EQNunjhvCSiX2f6E1QhQCHTwcquyk9khLUZhMjB8G11GFYGSL09bflZmDNdhkOhU3SIEKrrygZylT vGPQ8B60XjjBxg==; In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Sat, 04 Jan 2025 11:20:41 +0100) 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:298562 Archived-At: > From: Gerd Möllmann > Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org > Date: Sat, 04 Jan 2025 11:20:41 +0100 > > In callproc.c I found two: call_process and create_temp_file both use > SAFE_NALLOCA to store Lisp_Objects. I think these should be replaces > with SAVE_ALLOCA_LISP. What are the conditions under which placing Lisp objects into SAFE_NALLOCA is not safe? I understand that the first condition is that SAFE_NALLOCA uses xmalloc instead of alloca. But what are the other conditions? Is one of them that GC could happen while these Lisp objects are in the memory allocated by SAFE_NALLOCA off the heap? IOW, if no GC happen, is that still unsafe? And if GC _can_ happen, but we don't use the allocated block again, is that a problem? For example, in this fragment: SAFE_NALLOCA (args2, 1, nargs + 1); args2[0] = Qcall_process; for (i = 0; i < nargs; i++) args2[i + 1] = args[i]; coding_systems = Ffind_operation_coding_system (nargs + 1, args2); val = CONSP (coding_systems) ? XCDR (coding_systems) : Qnil; Let's say Ffind_operation_coding_system could trigger GC. But we never again use the args2[] array after Ffind_operation_coding_system returns. Is the above still unsafe? If so, could you tell what could MPS do during GC to make this unsafe? Also, in some other message you said SAFE_NALLOCA is unsafe if _pointers_ to Lisp objects are placed in the memory SAFE_NALLOCA allocates off the heap. In call_process I see that we only ever put Lisp objects into the memory allocated by SAFE_NALLOCA. If that is unsafe, could you tell what MPS does during GC which makes this unsafe? TIA