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: Fri, 03 Jan 2025 17:20:40 +0000 Message-ID: <87jzbbke6u.fsf@protonmail.com> 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="12038"; mail-complaints-to="usenet@ciao.gmane.io" To: 75322@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 03 18:21:26 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 1tTlMU-0002zw-MI for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Jan 2025 18:21:26 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTlMB-0005kX-8i; Fri, 03 Jan 2025 12:21: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 1tTlM8-0005kN-NA for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2025 12:21: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 1tTlM7-0001GC-Fk for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2025 12:21: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:From:Date:To:Subject; bh=UQrjUHGJD3++SRb5h06zyaePPN8a6dGuqwofgjSdeHg=; b=X16eGAz8aOfC4TRoXdQbe0xuRcrUhGv0rKT/A4BIJhxQmZg794gg2q8TIIE+C6yJZwL3LtKaSqCprH35zvbYQb6K8V5QhKgFAF8yQbJjxcGnccOA5oQEvvAGgL3PiiP6VamXfCKaKccG8TL7ODb7W102KVeczwVmoXDbZJWh2bLo62gL49e9Gb3Te5O7jkIDOrtxLOZh72nrKUwiX+vyUmLfRHEVeLvVXYvdT3dwUbkZxxhFzFr8MlZd26SOod5nSmmD/+4LdXdMPXmeBCNKudNPvCQU9ovieXugx51ALieySxv7C4xB0u1BC+nsxw/Bj2OHqXmAfwLQvTwMxms4uw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tTlM6-00041P-9e for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2025 12:21: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: Fri, 03 Jan 2025 17:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 75322 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.173592486115444 (code B ref -1); Fri, 03 Jan 2025 17:21:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 3 Jan 2025 17:21:01 +0000 Original-Received: from localhost ([127.0.0.1]:51901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTlM4-000411-W8 for submit@debbugs.gnu.org; Fri, 03 Jan 2025 12:21:01 -0500 Original-Received: from lists.gnu.org ([2001:470:142::17]:43908) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tTlM2-00040W-IA for submit@debbugs.gnu.org; Fri, 03 Jan 2025 12:20:59 -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 1tTlLu-0005jU-Ex for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2025 12:20:50 -0500 Original-Received: from mail-4322.protonmail.ch ([185.70.43.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tTlLr-0001Ek-D5 for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2025 12:20:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735924843; x=1736184043; bh=UQrjUHGJD3++SRb5h06zyaePPN8a6dGuqwofgjSdeHg=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector: List-Unsubscribe:List-Unsubscribe-Post; b=zVu+DYPwNtul2M2XAD61CKfZKY/puehiwn/XoUi6yqGdsH6qWwtHZvi6qZ9ZjixI/ DrS+YTUshNp8uJtyReTvlrPSZm7w1gwz2kliQNeuwtcY329bH5aTikWnYlBu2/akPz KixrM14DIEf9KuXfPSwOZyt+OwSXaiD1UunIck4z4YiYzpMbJ0DjbMkMn8LmeIvq/W RZhonrEuOsKO1DnjeIcdLRw1eg+ZYUfxcsNvQxUSIPc8ZjS8qilaVH6UDuXUmC7bdv Yc+7yK0+4Jhv1/tGlTXd5qMPkMJvfdjRcdSWNB6m+Y4Qp/JRu49TtumUMw6YjLF3Ue 1nGcX3szHQt7g== Feedback-ID: 112775352:user:proton X-Pm-Message-ID: b5c5b535d19e3968222ff93fd93a963c9aff9df7 Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@protonmail.com; helo=mail-4322.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:298292 Archived-At: process.c and callproc.c use ALLOCA to store arrays of Lisp_Object values, or arrays of pointers to string data. With the current GC, that is correct code only if it's provable that these objects are marked through some other reference to them (or we know no GC can happen), because if the last reference is hiding in a SAFE_ALLOCA'd buffer AND that buffer is not on the C stack, it will be collected. With MPS GC, it's even more important to do so, because the object might otherwise be moved, invalidating the pointer. This is a possible explanation for bug#75292. In either case, I don't immediately see that the current code would be safe. SAFE_ALLOCA doesn't call xmalloc very often: it usually uses alloca(), which results in data on the C stack, where it is visible to both garbage collectors. An alternative to fixing this bug in callproc.c and process.c (and reviewing every other use of SAFE_ALLOCA) would be to ensure that in the rare case that SAFE_ALLOCA memory is not on the stack, we'd still conservatively scan it for references. If we decide to retain the current SAFE_ALLOCA behavior, it is very important to test builds where SAFE_ALLOCA always uses xmalloc, so we have a chance to detect such bugs. Unfortunately, currently bidi.c and some other places assume that MAX_ALLOCA is "large enough" so this isn't a simple matter of defining that constant to be 0. A large stack footprint comes at a cost: it needs to be scanned during GC, but more importantly there is the risk of latent bugs because stack pages might not be accessed in the "right" order and the OS might assume that an excessively-offset access is a program bug rather than an attempt to allocate large amounts of stack; GCC on GNU/Linux currently tries to work around this issue by touching each 4096-byte page of the stack at least once, in the right order. Note that call_process already allocates more than 64 KB of stack space unconditionally (in an inner scope, but GCC hoists such allocations to the function frame). It may be a good idea not to use SAFE_ALLOCA at all in this function, unless the 64 KB allocation can be removed.