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 11:56:20 +0200 Message-ID: <865xmugawr.fsf@gnu.org> References: <87jzbbke6u.fsf@protonmail.com> <87msg7iq0o.fsf@protonmail.com> <86ed1jf1tp.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="18188"; 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 Sat Jan 04 10:57:17 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 1tU0uC-0004Z5-9P for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jan 2025 10:57:16 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tU0u1-00057I-5b; Sat, 04 Jan 2025 04:57: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 1tU0ty-00056z-ND for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 04:57:02 -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 1tU0ty-0001SY-F0 for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 04:57: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=EAu2ZPRz9IvyRqhxohivc6mEshMuJT1sCnUu3JeWF4Q=; b=DTk1XQdUtveALdug0ueGDZ8K8P2/iQgI9slVkwg2z4Vps+tif7OuGkjAHSnsnJfYCWH5xrWJj6VodiqE01lfR+FMN/GSAqlDht8wYSTC7+rxBDTRG3ofyh5OKkqbEhRZyDPwziaVPpaE5wiU8mAnrea+E8DXc3OmRsXrzbb1AtAqOHDGWn5qqAJEHi3OPB8+MWt/X3Criv5WYoQkYID1TOM/7NrkvUHvLf+8STP9xDkCB96DojGCSEJEcw8snR1i/2WWJ4vjWvEnSqypnRozALL3nRcuu5dPAwa4Ny0lhyMzS5Mm/sYgshmdj/xSQlBZXr+CahP79P+6DUlBi3PoCg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tU0ty-0006fO-9V for bug-gnu-emacs@gnu.org; Sat, 04 Jan 2025 04:57: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 09:57: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.173598459225573 (code B ref 75322); Sat, 04 Jan 2025 09:57:02 +0000 Original-Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 09:56:32 +0000 Original-Received: from localhost ([127.0.0.1]:53428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tU0tT-0006eO-NJ for submit@debbugs.gnu.org; Sat, 04 Jan 2025 04:56:32 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54008) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tU0tS-0006eA-8T for 75322@debbugs.gnu.org; Sat, 04 Jan 2025 04:56:31 -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 1tU0tL-0001PM-Ta; Sat, 04 Jan 2025 04:56:23 -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=EAu2ZPRz9IvyRqhxohivc6mEshMuJT1sCnUu3JeWF4Q=; b=SB5fi6CNjG1f85avAOk3 uwCYMYKFEnXsJtHyDsL7FZ978iV+JP57lvUzP6rzcYhRkYEy8dNYL78QFrfDy1ymQEKzNESeVJ+3r BocYVc5C847S45atjSJbkhuvpejwzGigG1HHCKRt/JzG3bZy/sfLTRDAdhgU2rwHqRJ3K8o+NHv6l 2w2dfgRvkQY/kY2JpXiYZcnRvgdv8Fb6043jAdZWaftaecOu2lE0Fo991/c9dKspE3bHTf/FPv9tv 0Hr8mWTKt66QBM7/oIb+xiWZA2sWwQBIsxBVHoYzpTYCj//OZN4CeSem5FQl7RY8k6VuiiZ8MHhps lkZLCZnnsIYbfw==; In-Reply-To: (message from Gerd =?UTF-8?Q?M=C3=B6llmann?= on Sat, 04 Jan 2025 09:47:43 +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:298351 Archived-At: > From: Gerd Möllmann > Cc: pipcet@protonmail.com, 75322@debbugs.gnu.org > Date: Sat, 04 Jan 2025 09:47:43 +0100 > > Eli Zaretskii writes: > > > Let's discuss this on a case by case basis. Not all uses of alloca > > are the same or have the same requirements and restrictions. > > Okay. For the SDATA case, I find Pip's commit does the right thing. It > uses xstrdup for the strings and makes sure these are freed later by > registering them in one of the special specpdl entries that exist for > that purpose (record_unwind_protect_ptr). Works with both GCs, is always > safe, I don't see disadvantages, and we don't have to check if GC runs > or not and compact strings (old) or moves string data around (igc). The disadvantage is to xstrdup strings when that is not needed. It increases memory pressure and also costs some CPU time. Not very significant disadvantage, admittedly, but still. If this is needed, it's a small price to pay, but if it isn't needed, it's a waste. So let's see if we agree that it is indeed needed. The way to do that is to explain how GC could happen while the code which assembles the environment in make_environment_block and the code in emacs_spawn afterwards run. Note that we block SIGCHLD and block input while emacs_spawn runs. > For the Lisp_Object cases, I strongly suspect that these cases are an > oversight and were left over when SAFE_ALLOCA_LISP was introduced. The > reason for introducing SAFE_ALLOCA_LISP is, IMO, what Pip said (old GC): > to make sure that the Lisp_Objects are marked, via specpdl stack entries > again, when the specpdl stack(s) are marked. Not doing that looks > definitely wrong. Replacing the other ALLOCA macros that are currently > used for holding Lisp_Objects with SAFE_ALLOCA_LISP would solve things > for both GCs. Can we first identify those cases, so that we could discuss the specific codes in question?