Received: (at 75322) by debbugs.gnu.org; 8 Jan 2025 03:46:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 07 22:46:36 2025
Received: from localhost ([127.0.0.1]:45489 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tVN1g-0001L5-8R
for submit <at> debbugs.gnu.org; Tue, 07 Jan 2025 22:46:36 -0500
Received: from mail-ej1-x633.google.com ([2a00:1450:4864:20::633]:54387)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>)
id 1tVN1d-0001Ku-Em
for 75322 <at> debbugs.gnu.org; Tue, 07 Jan 2025 22:46:35 -0500
Received: by mail-ej1-x633.google.com with SMTP id
a640c23a62f3a-aaeecbb7309so418756566b.0
for <75322 <at> debbugs.gnu.org>; Tue, 07 Jan 2025 19:46:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1736307992; x=1736912792; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=SbtMStVfdmEiHdZVvpQxwHpySF+Id3LsR7lCOEVxJ/I=;
b=Vclft1hXd27vASAXSAiZYXpvo2ztPbVv+LZm0OJbDmuVa8eyBB84Ute3oKTRSQlm9d
OdDyoWZms6g4fuGeX+lMkr/W1+kWYEYGqz5e8ejadx6b7H+tFQ9N1rTCcnLFOR29irzd
nY+HUBhlJi7wvyGFvS/B8k1MLlHl+XaGhnOohZ9aiSObIKY4CEXOYN2JsFth7CmMoZMx
69mUkOTbJ7JjOk4FN9L40yAP+njH0GP+1dawfw8XZm94NBn/2RRsS/wStJxklRCztM0Q
ATmrIb2A1nPVF/VY7wuEzS5tvGqwGQWVcHKw2ciOmcU6KdSZQuIzbkHTDq9ex3IzQ2C/
eTIw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1736307992; x=1736912792;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
:to:cc:subject:date:message-id:reply-to;
bh=SbtMStVfdmEiHdZVvpQxwHpySF+Id3LsR7lCOEVxJ/I=;
b=UIW24z+XsWGZ0oOrRgcxq2mb6z8i55r0jKpKfnYFMOQXES6Wv8zf0WJ5Cq71KJqZ2A
mGsIJB3TJAUflfJQHQX69UvBIXDXzBdZR6qb9G279N5opcbErFNwAm4Ep1hZduAQB4wQ
SbqbSB9J4tRhE17PuXNXEfzXNe/ed4Jb2tshV2ZaQRaJxE1gST29/ei0gSi88wV0uzv+
M11gZKZizjohYWWLZ9ya4Zd3mWlKXhGNppNz0NWbzwy2F72ygqi83Zrut0ZovIPdMR0B
47+AutG6w2Fv4diUEMC/pKoXkvwq4POXb4hiFidrOYBCrnt9UKBOXJ7ur2x54KP+ILKo
2gCg==
X-Forwarded-Encrypted: i=1;
AJvYcCVsLZdK8H9NxYpPT60Vi7lXXEu4E/8UMaasZ54pNvYAG29cAWbjH2FxOTzSpMZVWN+SgkOpDQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyNmMvdFIH85GxRSNIcVLkK32oHoWRWTgOBmanyqGNvSLuAt+/V
QqCtUpxt4hX2eq38AlNQBIXg8S4kubdabtPh/wpb+WrI9TMQqM/G
X-Gm-Gg: ASbGncs9K1kzMe753FKg+l8XXNx6sj+s5VoHkQVxhaJDr5F6vQ2NC7/WRM1zw0JQdth
u2k4Pev0XFREqKMUI9Rtz3Y6b90XnZ95i9M4TyOzGNQKi4qTsUxpKEJ8UvqGx6XyxpNnUi1+eHK
t7zhjb6x0sbv/XOCxNltKBwcynkcBHfjFaLtKfQY0yEimDm7U08zTkTxhMNvKJ22anw7nrCgZAY
+ZPBpmbR02tSuWl9q6CRx2KLp1DX+yQAHupKB3TdTLlTUvX3f2TATduXcYjCNCexH6YVY7UvCeV
g9UNgKJDJ9aSk7CsskWxNrLM+/8c8Z0aX6VVmtLCb2+xeBPEhXIktv5WURWi5ou8
X-Google-Smtp-Source: AGHT+IG4h1JOVP987ClBUoh70tN3ns4DiqEC3Ntw6uzX0r6kvf7kZRWTYXxYNqYLkPBf2tHZe1ts5g==
X-Received: by 2002:a17:907:d88:b0:aa6:5910:49af with SMTP id
a640c23a62f3a-ab2ab70a152mr86643566b.24.1736307991734;
Tue, 07 Jan 2025 19:46:31 -0800 (PST)
Received: from pro2 (p200300e0b70e79000ca159a4b0b99ee2.dip0.t-ipconnect.de.
[2003:e0:b70e:7900:ca1:59a4:b0b9:9ee2])
by smtp.gmail.com with ESMTPSA id
a640c23a62f3a-aac0f012229sm2440976466b.133.2025.01.07.19.46.29
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 07 Jan 2025 19:46:30 -0800 (PST)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@HIDDEN>
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
In-Reply-To: <m2cygzda7r.fsf@HIDDEN> ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?=
=?utf-8?Q?s?= message of "Mon, 06 Jan 2025 20:16:24 +0100")
References: <87jzbbke6u.fsf@HIDDEN> <87ttaee5qp.fsf@HIDDEN>
<86a5c6b9sb.fsf@HIDDEN> <87ikque0xp.fsf@HIDDEN>
<864j2dacuz.fsf@HIDDEN> <877c79eipq.fsf@HIDDEN>
<86ttad8v37.fsf@HIDDEN> <87ttadd25l.fsf@HIDDEN>
<86o70l8qt6.fsf@HIDDEN> <87zfk4gcpw.fsf@HIDDEN>
<m2cygzda7r.fsf@HIDDEN>
Date: Wed, 08 Jan 2025 04:46:29 +0100
Message-ID: <m24j2ac6i2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75322
Cc: Pip Cet <pipcet@HIDDEN>, Helmut Eller <eller.helmut@HIDDEN>,
Emacs Devel <emacs-devel@HIDDEN>, 75322 <at> debbugs.gnu.org,
Eli Zaretskii <eliz@HIDDEN>, Daniel Colascione <dancol@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
> (CC to emacs-devel and Helmut)
>
>> I give up. (Certainly on this discussion, maybe on scratch/igc, who
>> knows.)
>
> I propose that we, i.e. you Pip, Helmut, and me, ignore the subject of
> a possible merge to master in the future. That's an SEP, costs too much
> energy, and what happens is unpredictable.
>
> I'll begin with the ignoring by reverting a revert, adding Helmut's and
> my patches, merging master on the weekend. Sorry for any inconvenience
> that causes.
Now done a bit earlier.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 8 Jan 2025 03:46:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Jan 07 22:46:46 2025
Received: from localhost ([127.0.0.1]:45492 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tVN1q-0001LU-IW
for submit <at> debbugs.gnu.org; Tue, 07 Jan 2025 22:46:46 -0500
Received: from lists.gnu.org ([2001:470:142::17]:53718)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>)
id 1tVN1p-0001LF-24
for submit <at> debbugs.gnu.org; Tue, 07 Jan 2025 22:46:45 -0500
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 <gerd.moellmann@HIDDEN>)
id 1tVN1h-0007fO-IP; Tue, 07 Jan 2025 22:46:37 -0500
Received: from mail-ej1-x631.google.com ([2a00:1450:4864:20::631])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <gerd.moellmann@HIDDEN>)
id 1tVN1e-0003My-LP; Tue, 07 Jan 2025 22:46:36 -0500
Received: by mail-ej1-x631.google.com with SMTP id
a640c23a62f3a-aa6a92f863cso425354666b.1;
Tue, 07 Jan 2025 19:46:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1736307992; x=1736912792; darn=gnu.org;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=SbtMStVfdmEiHdZVvpQxwHpySF+Id3LsR7lCOEVxJ/I=;
b=lFHLYY5m4ZatbtfuJIaTtdXoM6zGZcx6sFaXM6mPUWsnkikD4JOX4ZC7dF6H1XStG3
BekQu3zc+Fv3SG5qWrp9ibQh5mZ7kzIUkq93hvUfa46x5qgR+s/zcpcYzVHUeKuTbLrh
9XomuuyE02vXziMIQWFazfZgwPB1NCZM0IJjAb8LLJFSLXQmjhzTsTFKF/BquiSe704F
t7HfzUuympProVUiFIat3clCTbOKt4YwWdtN1Jj9h/SrZLfzk+A7qRbcy3UmN6Uu1NiR
ecYOasgiWIyAUxcVe0k9fsov2y0f/bWPNWCfipX1BOYOOfwl8irZ/pgFJGNFWTHRTfWS
ET5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1736307992; x=1736912792;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
:to:cc:subject:date:message-id:reply-to;
bh=SbtMStVfdmEiHdZVvpQxwHpySF+Id3LsR7lCOEVxJ/I=;
b=ZHMuDP4HApM1LT1Ht5sbNKMW31l44/RoTwTjtlziHv5fxqwO/0FgQ5wA3NPhmgaprh
li4WmZYktuAaKOyva52GwZJPFdsKsMB/nAwRjBW87KI+G5jq2EXzwp7GXTBccNAc+TfR
c9F+qhwpFS9Wji+ZBLVmxM/Rkqb+QQcvfdJjsRjbpw+n68PSjATR7wl9czkxmPF5lykI
UKti/stHU/IkqNOycGKZ45aI14Mz5S1vIRRqXlpHAsM4z886sNkownkyHUXfJA7IvM3L
1F4/wOyft69X2fexusqTKNDdsmswve3ykhypWB4XFK3fB1M028OLD8IE54xRw/Yk+ihH
ngLg==
X-Forwarded-Encrypted: i=1;
AJvYcCV4EEV1n0l9Rs5adQwlUn+l/MRBXqpyj8IM7hD+DZ77CyrWgecS9oC53ZbJfwxtKhP/eYtOYuJAUMjUgA==@gnu.org
X-Gm-Message-State: AOJu0Yyzw5VJG2jcQA3ZGtWVhSkOSq01DnGt/qGm4SaCEj6AiOv2Haza
vmOYcs4d6pDv5qjlFEmhLu4+ry4gFeOyKFwIIil29z8wfvYBq9at
X-Gm-Gg: ASbGncvm3OtiTKNwY23YpapFAJciDZOvrza8WdNIAzCBCKIKUyW7B3kpKOHOMPyUpRl
Er0xgu1MuXHGsYkbAzmthnUyN/1+utVrpFgFokP631BmVUnEfM/rjeOyqK/SUWHReGCyKtW7k+T
afST6Ek9oSjGRAm+/DOgLEcYZBZDx4NAidxe4weEIabHMrOgHr58RllHhroDYKKP1YEDWL0sL5Y
SxTjPgndFkWtUezsqZtsDC6bY+cOZ0UliLyxf68dTy/bSas5G8QQv3zrBsThfBQ2qwP0mWImyMg
2esdc69SAOXLdzSvJM2ESLgn/VaB7mL2QXvtMXKYOViHMxrXtSF86qOhKMaSWWgm
X-Google-Smtp-Source: AGHT+IG4h1JOVP987ClBUoh70tN3ns4DiqEC3Ntw6uzX0r6kvf7kZRWTYXxYNqYLkPBf2tHZe1ts5g==
X-Received: by 2002:a17:907:d88:b0:aa6:5910:49af with SMTP id
a640c23a62f3a-ab2ab70a152mr86643566b.24.1736307991734;
Tue, 07 Jan 2025 19:46:31 -0800 (PST)
Received: from pro2 (p200300e0b70e79000ca159a4b0b99ee2.dip0.t-ipconnect.de.
[2003:e0:b70e:7900:ca1:59a4:b0b9:9ee2])
by smtp.gmail.com with ESMTPSA id
a640c23a62f3a-aac0f012229sm2440976466b.133.2025.01.07.19.46.29
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Tue, 07 Jan 2025 19:46:30 -0800 (PST)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text
editors" <bug-gnu-emacs@HIDDEN>
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
In-Reply-To: <m2cygzda7r.fsf@HIDDEN> ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?=
=?utf-8?Q?s?= message of "Mon, 06 Jan 2025 20:16:24 +0100")
References: <87jzbbke6u.fsf@HIDDEN> <87ttaee5qp.fsf@HIDDEN>
<86a5c6b9sb.fsf@HIDDEN> <87ikque0xp.fsf@HIDDEN>
<864j2dacuz.fsf@HIDDEN> <877c79eipq.fsf@HIDDEN>
<86ttad8v37.fsf@HIDDEN> <87ttadd25l.fsf@HIDDEN>
<86o70l8qt6.fsf@HIDDEN> <87zfk4gcpw.fsf@HIDDEN>
<m2cygzda7r.fsf@HIDDEN>
Date: Wed, 08 Jan 2025 04:46:29 +0100
Message-ID: <m24j2ac6i2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Received-SPF: pass client-ip=2a00:1450:4864:20::631;
envelope-from=gerd.moellmann@HIDDEN; helo=mail-ej1-x631.google.com
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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: submit
Cc: Pip Cet <pipcet@HIDDEN>, Helmut Eller <eller.helmut@HIDDEN>,
Emacs Devel <emacs-devel@HIDDEN>, 75322 <at> debbugs.gnu.org,
Eli Zaretskii <eliz@HIDDEN>, Daniel Colascione <dancol@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.0 (/)
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
> (CC to emacs-devel and Helmut)
>
>> I give up. (Certainly on this discussion, maybe on scratch/igc, who
>> knows.)
>
> I propose that we, i.e. you Pip, Helmut, and me, ignore the subject of
> a possible merge to master in the future. That's an SEP, costs too much
> energy, and what happens is unpredictable.
>
> I'll begin with the ignoring by reverting a revert, adding Helmut's and
> my patches, merging master on the weekend. Sorry for any inconvenience
> that causes.
Now done a bit earlier.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 19:16:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 06 14:16:33 2025 Received: from localhost ([127.0.0.1]:40116 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUsaX-0005gM-IC for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 14:16:33 -0500 Received: from mail-ed1-x533.google.com ([2a00:1450:4864:20::533]:52596) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUsaW-0005fy-8b for 75322 <at> debbugs.gnu.org; Mon, 06 Jan 2025 14:16:32 -0500 Received: by mail-ed1-x533.google.com with SMTP id 4fb4d7f45d1cf-5d3f28881d6so21912853a12.1 for <75322 <at> debbugs.gnu.org>; Mon, 06 Jan 2025 11:16:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736190986; x=1736795786; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=ejJtsijrBRKao0sNNlxDn22q4sGORHz5a5wkqHG4SpY=; b=BpIBvcj0PKX70sUZ7DlVhH0zVSs0Aq9yjByVJRHcioPttTLP4T6FSpaZBSR9FIhYmT W1rlnAVqmXjeX2dHj0coGf3ZLUkehoq6+MwzWRkb1QL901zz94nQPaUpvEK9ppSnU4uW QZynGvzef8OZb5YgZks8oMHRB2PhY1qAtAGUybEv16Km6P/N6GI5y0qc6EWpV0AEjh2r yIHLT71dFxd2XQHfy0nsS1r2mbzdhjn/P6S1g2C7IwLlf5FwsExrO1/thW/9y99Zumdo wyWBa9hQ1/tqjDum5/gAk6Qkzc6gRLDkbfVqQxjw0M3pSJFGJWFRMZVVCA5VuM7Uy0xt XGZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736190986; x=1736795786; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ejJtsijrBRKao0sNNlxDn22q4sGORHz5a5wkqHG4SpY=; b=j27b1M6q1kkJP2sgvYMi4PVXwbx81n4qBD+Grj9qcyIUiMofYI/TniYEVlqcaD6q/X vnNrbptLpb1zaCbbo+eq62z1yKzoACE50urosLLEIAAQyDx9DXBcE3LjlCmq8yO08KiD vkAi9kGJ8cELeD3JAj0mZWhFppdRYVM6BpFnzLF0X1mXcArcUcDyCwVWYmhstCXKho/K uf9/hB/s+u2UdtO8jyTwjtJmVgqtscsNdFyamTFYRi69UlflsoVukk95pw7OC/i18adK oDt+qxLcgCwTlj1CrK/Y4xmMowBiKkOwg6vJF3HbAyAcmpY/MWVU/pUZWaNYdrHDJI4Q o6fg== X-Forwarded-Encrypted: i=1; AJvYcCXZbhJjVN3wGO5yntsjtHmop9J5roLNH41hKFYdP+UyDnGK8waoqERAqpQYWy9SOFSFh4KtXA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yw/5TLsYLh+f6iSfpmDXOXTiXuv8KQSd7Ju0bvzY4KAMEbr/F1k XdE88hTSib+5A3Tcn2+nsH8/e6PNivFxhbAx8BupjfvgieNx+FyM X-Gm-Gg: ASbGncve1zk5G6khUiNBcSsx/FESiGBc99lCQQ/s5zRRvdSm/j+ixn1byf2Z7RY9oDt Av5+pzKc46oGwquibDaRdDjNvj9hR6bsUS5VaA8AVPqKsF79XRGEnAmRAmWkbI8OT/BGQJfDuxx Fr5G6KnCwivu4GTh85TJsLiLHKhbYDXTIJVRWyVYzWZc4a7OJ5aWnLOaX58kmTFw1cFPoh4jifB BpNT0sa0qQ1xkouaGBcTHk8S1sb53j4/xBGdfpWOsTbmFl1hS2jer8Fde6Y5U0oHfPpjVpMNUEo GnL5LMrAc+tULI8ePIbwnESDW1bTSAWhasbDlMkQufKrOaFsFI2NVIsr8F34n0iXcw== X-Google-Smtp-Source: AGHT+IEWCcftuWDysO3YI4Sv5BoAyVJ5AdS3BUFjatAijftLF17jIyS4V4eBf8R2GnLZ82TTXrvcNA== X-Received: by 2002:a05:6402:27d2:b0:5d0:c697:1f02 with SMTP id 4fb4d7f45d1cf-5d81ddc0609mr134782991a12.17.1736190985869; Mon, 06 Jan 2025 11:16:25 -0800 (PST) Received: from pro2 (p200300e0b74e69004d937c306cf91eca.dip0.t-ipconnect.de. [2003:e0:b74e:6900:4d93:7c30:6cf9:1eca]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0f014c94sm2276229666b.158.2025.01.06.11.16.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jan 2025 11:16:25 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <87zfk4gcpw.fsf@HIDDEN> (Pip Cet via's message of "Mon, 06 Jan 2025 15:54:07 +0000") References: <87jzbbke6u.fsf@HIDDEN> <87ttaee5qp.fsf@HIDDEN> <86a5c6b9sb.fsf@HIDDEN> <87ikque0xp.fsf@HIDDEN> <864j2dacuz.fsf@HIDDEN> <877c79eipq.fsf@HIDDEN> <86ttad8v37.fsf@HIDDEN> <87ttadd25l.fsf@HIDDEN> <86o70l8qt6.fsf@HIDDEN> <87zfk4gcpw.fsf@HIDDEN> Date: Mon, 06 Jan 2025 20:16:24 +0100 Message-ID: <m2cygzda7r.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: Pip Cet <pipcet@HIDDEN>, Helmut Eller <eller.helmut@HIDDEN>, Emacs Devel <emacs-devel@HIDDEN>, 75322 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Daniel Colascione <dancol@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) (CC to emacs-devel and Helmut) > I give up. (Certainly on this discussion, maybe on scratch/igc, who > knows.) I propose that we, i.e. you Pip, Helmut, and me, ignore the subject of a possible merge to master in the future. That's an SEP, costs too much energy, and what happens is unpredictable. I'll begin with the ignoring by reverting a revert, adding Helmut's and my patches, merging master on the weekend. Sorry for any inconvenience that causes.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 6 Jan 2025 19:16:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 06 14:16:49 2025 Received: from localhost ([127.0.0.1]:40119 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUsai-0005gy-Tv for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 14:16:49 -0500 Received: from lists.gnu.org ([2001:470:142::17]:59176) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUsag-0005gb-Ge for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 14:16:42 -0500 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 <gerd.moellmann@HIDDEN>) id 1tUsaU-0004yJ-Tf; Mon, 06 Jan 2025 14:16:36 -0500 Received: from mail-ej1-x636.google.com ([2a00:1450:4864:20::636]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUsaS-0007R3-Lv; Mon, 06 Jan 2025 14:16:30 -0500 Received: by mail-ej1-x636.google.com with SMTP id a640c23a62f3a-aa6c0dbce1fso2060775266b.2; Mon, 06 Jan 2025 11:16:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736190986; x=1736795786; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=ejJtsijrBRKao0sNNlxDn22q4sGORHz5a5wkqHG4SpY=; b=k9t33CA+BD9cBIGCK6FhDPtw+Af/g4LbktgAkoF7oow8UDtDfsPT0fUDn4qdxs6GOH FAuv9Rol3t0i8Obb2Gl41h5wrjM4kA0Ql5T7Q+ZIKFpgLw5MUymRIuYlIOZoLEJp2raV pRL2ECFE1p/GS5I/LBsndq75o72jyEcCYgYOhT9pk8xpzmhPcxsU5tPcPFd4gphsEjlE CVG55LZR0HSxDuAbbIOqkf0UqtFyxysgiIsSgAU3kbt7+GrDY6INgWhoHRiB2WT13mOU qSxZ4pwx83pYFmZ8ZjUyzqeHWRL4hvs+/EH8GgoUTkGcel6/f64jIoNsDQTJyHGSU59l Drbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736190986; x=1736795786; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ejJtsijrBRKao0sNNlxDn22q4sGORHz5a5wkqHG4SpY=; b=B7XlgBIs+WGI5XbvUTmihSbbxeioiQ81UO0BcIeG/jfA78kAa1FD0HbtkiMcLpanNw 3D2SM16Mr8S6mzVMk+49OQa/tjzTYa1NMmj1j8fHIHqy83r+1HkxPmFVbs2Lnt1XaIY4 LnzUB8eJmBqlLIMbtjkCwPdVp24Up3BSASyeDmSQENevE1bq9tNlLZ83nLtEoRnDyPXS Ey8uch/sSS1Xs2i+ErW7Z0dXOgksghIErnvMnA8iq2PTIs8w96x8VeUODEBqKCZUMI0z AtfW4FIPMB1EqmGRf0HIGIp4w/ThOan8tdhUsq7IEq+TaBWyOA7oY4hakPBPvKCoRE/Q +yAw== X-Forwarded-Encrypted: i=1; AJvYcCW7yYINSpQlpDjxIynUENH75dovCrXfGsGpfeRVMok0rOjDQ9zixR095nTXCKHvmLKa8K0YIRpD4EJpEw==@gnu.org X-Gm-Message-State: AOJu0YyUoa0pWiWRqxBnu96ZXyEmMy8D9++zZzbyum9YMhzbh+XsYDnr HMmviqmsH5RyZSKsb1LNaWoZvRfw+9/Z45+AeGnFKOAJLuCFvfTup+J0lw== X-Gm-Gg: ASbGnctSBTXcWlHAT2nilr0pJOrOLWuaG3S7ToanJSKe6uokY6Tg6YfGgIZx1KtVxIU /v7PoRlFqYfbtFfNNRCEbXRyBlpsnCFzvrs/nFBuL+09wQaBexmIuTQmB45De3DtMqXcT64PWyr n6NimN8pADfYdwUv4jn8bPBw3r9c4N8Z2vaOOnSyjR2FFftvwqXcO4Kl6/ZcNu+qcFfSWjW1UsU ZO1USIagVI2lb4UDcB4yHw/qMrmbpJX3/jcit8hxG6ySt2SxbtS56fXra++IfOyAZ+uFK/8dCc9 tbXroH5Aihn5XRrbvMeHVztbBO5/N/an9WYWDOYHMp1RXMnvA/CpxKYqxiitTU8RPg== X-Google-Smtp-Source: AGHT+IEWCcftuWDysO3YI4Sv5BoAyVJ5AdS3BUFjatAijftLF17jIyS4V4eBf8R2GnLZ82TTXrvcNA== X-Received: by 2002:a05:6402:27d2:b0:5d0:c697:1f02 with SMTP id 4fb4d7f45d1cf-5d81ddc0609mr134782991a12.17.1736190985869; Mon, 06 Jan 2025 11:16:25 -0800 (PST) Received: from pro2 (p200300e0b74e69004d937c306cf91eca.dip0.t-ipconnect.de. [2003:e0:b74e:6900:4d93:7c30:6cf9:1eca]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-aac0f014c94sm2276229666b.158.2025.01.06.11.16.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Jan 2025 11:16:25 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <87zfk4gcpw.fsf@HIDDEN> (Pip Cet via's message of "Mon, 06 Jan 2025 15:54:07 +0000") References: <87jzbbke6u.fsf@HIDDEN> <87ttaee5qp.fsf@HIDDEN> <86a5c6b9sb.fsf@HIDDEN> <87ikque0xp.fsf@HIDDEN> <864j2dacuz.fsf@HIDDEN> <877c79eipq.fsf@HIDDEN> <86ttad8v37.fsf@HIDDEN> <87ttadd25l.fsf@HIDDEN> <86o70l8qt6.fsf@HIDDEN> <87zfk4gcpw.fsf@HIDDEN> Date: Mon, 06 Jan 2025 20:16:24 +0100 Message-ID: <m2cygzda7r.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::636; envelope-from=gerd.moellmann@HIDDEN; helo=mail-ej1-x636.google.com 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: Pip Cet <pipcet@HIDDEN>, Helmut Eller <eller.helmut@HIDDEN>, Emacs Devel <emacs-devel@HIDDEN>, 75322 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Daniel Colascione <dancol@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.0 (/) (CC to emacs-devel and Helmut) > I give up. (Certainly on this discussion, maybe on scratch/igc, who > knows.) I propose that we, i.e. you Pip, Helmut, and me, ignore the subject of a possible merge to master in the future. That's an SEP, costs too much energy, and what happens is unpredictable. I'll begin with the ignoring by reverting a revert, adding Helmut's and my patches, merging master on the weekend. Sorry for any inconvenience that causes.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 15:54:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 06 10:54:20 2025 Received: from localhost ([127.0.0.1]:39749 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUpQp-0003rE-U0 for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 10:54:20 -0500 Received: from mail-40133.protonmail.ch ([185.70.40.133]:62103) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tUpQn-0003qz-HO for 75322 <at> debbugs.gnu.org; Mon, 06 Jan 2025 10:54:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736178850; x=1736438050; bh=8jteqz6PZze3rR28yPhvHJQuCKeSw8cDf2bpziHiLyY=; 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=ht7aTNpUAFocarqVqjclIfYf0f6Ai+bKdClY63AXMoPqDNZ9mmpevCM8cf7Vwppmj Iaj3/6WE/GV0rQk8VrW7AFt0hgOO4NEjL816C3qP1OwwwCdDEc+9lUVrw3piK+MTsA Bl78v6VtS81hy8uFzpLeIeTchveiqvRWmzas3pB43bVrPv6VLpQx/qr0YnphSR1BSe aYQThj4TJi5tPIuNQy6IY+OZJ2o5IyTRc3KZOomDFSmmHJ12aUrjr+EwnFmgrp01vO z5pU6uXpjp/bYuNoMn3mO5bcJo4bG3V6iIOuZkDYCpIzNtnIOQBXBL7GugjAnlytGe kdE+DBKb501bQ== Date: Mon, 06 Jan 2025 15:54:07 +0000 To: Eli Zaretskii <eliz@HIDDEN>, Daniel Colascione <dancol@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Message-ID: <87zfk4gcpw.fsf@HIDDEN> In-Reply-To: <86o70l8qt6.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <87ttaee5qp.fsf@HIDDEN> <86a5c6b9sb.fsf@HIDDEN> <87ikque0xp.fsf@HIDDEN> <864j2dacuz.fsf@HIDDEN> <877c79eipq.fsf@HIDDEN> <86ttad8v37.fsf@HIDDEN> <87ttadd25l.fsf@HIDDEN> <86o70l8qt6.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0fea7356a28156924a1f6ecc64e2ae063ecdcf80 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> As long as you think MPS requires us to avoid GC in this case (this is >> implied by "we must do this or that after GC"), your understanding of >> how scratch/igc uses MPS is fundamentally incorrect. > > Maybe my understanding is incorrect, but this style of "discussion", > where you are working hard to prove at all costs that I misunderstand > the issues and to point out my mistakes, contributes nothing at all to > understanding. It only contributes to confusion. I thought it was the only way for me to get you to even consider the possibility that your ideas of how GC works with MPS may need to be corrected. Given your message, I currently think there is no way for me to do so at all. I give up. (Certainly on this discussion, maybe on scratch/igc, who knows.) The MPS-based GC in scratch/igc does not allow or require general Emacs C code to make "no GC here" assumptions. Pip
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 15:27:39 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 06 10:27:39 2025 Received: from localhost ([127.0.0.1]:39698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUp10-0002Vp-MZ for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 10:27:39 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]:40454) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1tUp0x-0002Vc-JK for 75322 <at> debbugs.gnu.org; Mon, 06 Jan 2025 10:27:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=lXZWwtcIDDCmRMVbGWNO8L52cmgNjQRQ0zPut/0W/04=; b=Z6KnYWDo8t7uQKvx0ZH3i9KVlX F5ezPmZNo1uHBDp8Y/RxTfJ1feUsXRBvvaKC+uJtAyG9RWMpomVs83Epb6cRy62RobN6SILaxuB6M pzcIrjFEc4tBBvI8r5djmsc78bwLLUEzvMibl73ay9JCmKOi9liaLRHNdOaUoHhk0yk5NROqrGg2y e6FK5yxFctJs46OPKqsD5UGeApXua2a/FAfN0FWFbHNH1w+faDpgTKNqyYqtCnT/29nnFEMqKEKMt qmc2SNRvV1wBD5BAsUjpvJUMDMJnhFFr55ZIQSWXBsbOI2FkaVOTNlB1hQ/3HfSL1HmkGFUnh7lpv 19UG3Dxg==; Received: from [2600:1006:b124:d0da:0:51:7436:4301] (port=55208 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1tUp0q-0002h8-1i; Mon, 06 Jan 2025 10:27:28 -0500 Date: Mon, 06 Jan 2025 10:27:26 -0500 From: Daniel Colascione <dancol@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2375322=3A_SAFE=5FALLOCA_assumed_?= =?US-ASCII?Q?to_root_Lisp=5FObjects/SSDATA=28string=29?= User-Agent: K-9 Mail for Android In-Reply-To: <86h66c562y.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> <86msg56to8.fsf@HIDDEN> <m25xmtt9a6.fsf@HIDDEN> <86h66d6pw1.fsf@HIDDEN> <4B76EB57-AA29-40BC-8361-0906E00A3578@HIDDEN> <867c786quc.fsf@HIDDEN> <87wmf8t2vq.fsf@HIDDEN> <86h66c562y.fsf@HIDDEN> Message-ID: <489E3C1A-0423-4902-9805-6565C3DECE8F@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: gerd.moellmann@HIDDEN, pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On January 6, 2025 10:12:53 AM EST, Eli Zaretskii <eliz@gnu=2Eorg> wrote: >> From: Daniel Colascione <dancol@dancol=2Eorg> >> Cc: gerd=2Emoellmann@gmail=2Ecom, pipcet@protonmail=2Ecom, 75322@debb= ugs=2Egnu=2Eorg >> Date: Mon, 06 Jan 2025 09:48:09 -0500 >>=20 >> I wouldn't call it a "rewrite"=2E If auditing the codebase for memory >> safety is a "rewrite", I'm a "duck"=2E We're talking about a few hundr= ed >> lines of changes at the most=2E Most of the work is just auditing the >> code for problems=2E We should be grateful Gerd has done this work >> already, not "run away from MPS, fast"=2E > >I _am_ grateful to Gerd (and Helmut, and Pip, and others who work on >this)=2E I also invested a significant, albeit smaller, effort on my >part into this branch=2E However, the potential amount of changes still >bothers me=2E I understand it doesn't bother you, so I guess we >disagree in our estimations=2E > >> > SAFE_NALLOCA (args2, 1, nargs + 1); >> > args2[0] =3D Qcall_process; >> > for (i =3D 0; i < nargs; i++) args2[i + 1] =3D args[i]; >> > coding_systems =3D Ffind_operation_coding_system (nargs + 1, arg= s2); >> > val =3D CONSP (coding_systems) ? XCDR (coding_systems) : Qnil; >> > >> > "Look, ma: no pointers!" >>=20 >> Lisp_Object val, *args2; >>=20 >> In the C programming language, "*" means "pointer"=2E > >Are we going to argue about pointers and arrays? > >> > So this code needs to be changed=2E >>=20 >> The snippet you quoted above can be fixed with a one-liner --- replace >> SAFE_NALLOCA with SAFE_ALLOCA_LISP=2E > >It's just one example, and there are many like it=2E So that one-liner >is multiplied many times=2E > >And then we have variations, where args[] gets text of strings or some >other similar stuff=2E Etc=2E etc=2E > >> > And if you look around, we have quite a lot of these in many places= =2E >>=20 >> Sounds like Gerd's spent some time hunting them down=2E > >Sure, but I'm afraid there are many more=2E > >> > We have almost 200 static >> > Lisp_Object variables, probably not all of them staticpro'd (8 of the= m >> > inside functions, like the above example, so definitely not >> > staticpro'd)=2E So now we need to examine the uses of all of them an= d >> > either staticpro them or do something else (like move the assignment >> > to 'last_coding' to after call_some_function)=2E >>=20 >> Changing eight variables from function statics to file statics hardly >> seems like a monumental effort=2E > >After you found them, and after you know they should be changed, yes=2E >It's easy to account for the knowns; the problem is always the >unknowns=2E That's why most effort estimations are inaccurate=2E I >wonder what are our unknowns here, and how many of them are there=2E I'm a lot less worried than you are about the unknown unknowns=2E I have a= few specific reasons why: 1) we caught most of the movement-unsafe global references when we did pdu= mper, which, like MPS, moves things around in memory and so has to worry ab= out the kind of unsafe references we're discussing here=2E 2) when I did my own moving GC a few years ago, I didn't run into serious = problems with movement-unsafe references, although, like Gerd and others ha= ve done on the MPS branch, I had to fix a few 3) it should be possible (I don't know whether MPC implements this or not,= but it could) to arrange for a debugging mode moving GC that moves *everyt= hing* not pinned from the from-space to a non-overlapping to-space, then ap= plies PROT_NONE to any part of the from-space not used for a pinned object= =2E This way, any GC-invisible Lisp_Obiects (or other pointers) "left behin= d" because we forgot to tell the GC about them will produce an immediate SI= GSEGV when used=2E We could even conservatively scan for them=2E=20 #3 is probably overkill, but it's something we could try if we attempted t= o merge MPS and found chronic problems=20 >> The static-storage global-scope >> Lisp_Object variables are probably almost all gcproed already=2E > >Maybe=2E But someone needs to verify that, right? A few people have already done things like this over the years=2E
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 15:13:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 06 10:13:10 2025 Received: from localhost ([127.0.0.1]:39654 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUomz-0001kJ-U8 for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 10:13:10 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47026) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUoms-0001jk-RV for 75322 <at> debbugs.gnu.org; Mon, 06 Jan 2025 10:13:08 -0500 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 <eliz@HIDDEN>) id 1tUomn-0003HF-Ij; Mon, 06 Jan 2025 10:12:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=NGQ4xJ2MP8vShfuPNlShMVKondQZggQqhHiyMtt36Qw=; b=kJYDyWkjuzlP ZSvAc4cu8R+y7ZLaP5KyNiBH7Nfz+EXv/Jc8iVcPgl0wck61l47Bdc8GlJwXdLNSz8xSAQAAA3e0C Npxf55U4xpzgSm3zIRHw6eGvvFIbtlVO+cmCbIVNKuYa8hHOmy/2jNR0cUGejeZNlLe3QXePIkyKq JX3V05SdinibnnOJeWPs9Kje7HsUprXT+afm9T2MLBCDqJOg9ZXyMsFWm0+Fm9SBz3UwyqYaSyqDR WliCnYenI1S4FkjlhUNkGFhWNvjJ5ThEhBeAVOKpwnyuxgEpywkt8erosNf1fPxBoIF8fF1okhT1V WNm/08bzn6B8cuVkCUTOqA==; Date: Mon, 06 Jan 2025 17:12:53 +0200 Message-Id: <86h66c562y.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Colascione <dancol@HIDDEN> In-Reply-To: <87wmf8t2vq.fsf@HIDDEN> (message from Daniel Colascione on Mon, 06 Jan 2025 09:48:09 -0500) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> <86msg56to8.fsf@HIDDEN> <m25xmtt9a6.fsf@HIDDEN> <86h66d6pw1.fsf@HIDDEN> <4B76EB57-AA29-40BC-8361-0906E00A3578@HIDDEN> <867c786quc.fsf@HIDDEN> <87wmf8t2vq.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: gerd.moellmann@HIDDEN, pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Daniel Colascione <dancol@HIDDEN> > Cc: gerd.moellmann@HIDDEN, pipcet@HIDDEN, 75322 <at> debbugs.gnu.org > Date: Mon, 06 Jan 2025 09:48:09 -0500 > > I wouldn't call it a "rewrite". If auditing the codebase for memory > safety is a "rewrite", I'm a "duck". We're talking about a few hundred > lines of changes at the most. Most of the work is just auditing the > code for problems. We should be grateful Gerd has done this work > already, not "run away from MPS, fast". I _am_ grateful to Gerd (and Helmut, and Pip, and others who work on this). I also invested a significant, albeit smaller, effort on my part into this branch. However, the potential amount of changes still bothers me. I understand it doesn't bother you, so I guess we disagree in our estimations. > > 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; > > > > "Look, ma: no pointers!" > > Lisp_Object val, *args2; > > In the C programming language, "*" means "pointer". Are we going to argue about pointers and arrays? > > So this code needs to be changed. > > The snippet you quoted above can be fixed with a one-liner --- replace > SAFE_NALLOCA with SAFE_ALLOCA_LISP. It's just one example, and there are many like it. So that one-liner is multiplied many times. And then we have variations, where args[] gets text of strings or some other similar stuff. Etc. etc. > > And if you look around, we have quite a lot of these in many places. > > Sounds like Gerd's spent some time hunting them down. Sure, but I'm afraid there are many more. > > We have almost 200 static > > Lisp_Object variables, probably not all of them staticpro'd (8 of them > > inside functions, like the above example, so definitely not > > staticpro'd). So now we need to examine the uses of all of them and > > either staticpro them or do something else (like move the assignment > > to 'last_coding' to after call_some_function). > > Changing eight variables from function statics to file statics hardly > seems like a monumental effort. After you found them, and after you know they should be changed, yes. It's easy to account for the knowns; the problem is always the unknowns. That's why most effort estimations are inaccurate. I wonder what are our unknowns here, and how many of them are there. > The static-storage global-scope > Lisp_Object variables are probably almost all gcproed already. Maybe. But someone needs to verify that, right?
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 15:08:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 06 10:08:57 2025 Received: from localhost ([127.0.0.1]:39644 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUoiv-0001XK-1z for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 10:08:57 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]:37570) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1tUoit-0001X9-02 for 75322 <at> debbugs.gnu.org; Mon, 06 Jan 2025 10:08:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=bsPWXbLzSAbCmAW/UBLqjyJWYQ9ThESg4ADsIdOkTsE=; b=HROWyIsNlAq2oHovwWPpK7+Meh lgDWwMNhuKL0cYa/Rhny2841ku25Y+i5iA4v0F+QlzZQIwDMPCjp3xxxOOE4a5Y+w4LjhLO7EjUCu dJOYIOpx+rRCpvcDBBdI23oKMg3FmTjlsz1gvKnAg6hWzKbzYs6jLw/HETR1+jZ3LbbZcAQkxTpLb 8wGzOQT978h/QFXccOO9V8k4zLUOrE6fTCFbrvEKZfXBU/UuYMSVESuQEbMdu3RhZXK0lgw01xGhK LiVXU7khCJHxsLf0TVIxUqmJjeyT5csfXHH4Ln+5lQV3WbNdf7sf2eSCSqfmkyZ6brdZhri2pDaMt TFxoHwJw==; Received: from 2603-9001-4203-1ab2-fab1-0408-e627-6f43.inf6.spectrum.com ([2603:9001:4203:1ab2:fab1:408:e627:6f43]:49740 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1tUoiq-0002bU-0f; Mon, 06 Jan 2025 10:08:53 -0500 Date: Mon, 06 Jan 2025 10:08:49 -0500 From: Daniel Colascione <dancol@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2375322=3A_SAFE=5FALLOCA_assumed_?= =?US-ASCII?Q?to_root_Lisp=5FObjects/SSDATA=28string=29?= User-Agent: K-9 Mail for Android In-Reply-To: <86v7us5b0o.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> <225431A0-98C1-4F95-B290-AB86F5379030@HIDDEN> <87sepwvo04.fsf@HIDDEN> <86v7us5b0o.fsf@HIDDEN> Message-ID: <140EF998-8D55-4FB4-A8D1-C4F27152D4C1@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: gerd.moellmann@HIDDEN, pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On January 6, 2025 8:26:15 AM EST, Eli Zaretskii <eliz@gnu=2Eorg> wrote: >> From: Daniel Colascione <dancol@dancol=2Eorg> >> Cc: gerd=2Emoellmann@gmail=2Ecom, eliz@gnu=2Eorg, pipcet@protonmail= =2Ecom >> Date: Sun, 05 Jan 2025 18:28:59 -0500 >>=20 >> Daniel Colascione <dancol@dancol=2Eorg> writes: >>=20 >> Here's a demonstration of the problem=2E Run =2E/emacs -batch -Q --eva= l >> '(acos 0)'=2E If you leave demo_crash to true, Emacs will abort quickl= y >> after we detect a use-after-free=2E If you set demo_crash to false, Em= acs >> will run the loop all day=2E > >It is a well-known fact that inserting Fgarbage_collect in various >random places can cause bugs=2E=20 It's not a "random place"=2E It's demonstrating an unsafe pattern=2E > But expecting every Emacs C-level >hacker to write code that will endure such testing is impractical=2E =20 If someone can't write safe Emacs C code, he shouldn't be writing Emacs C = code at all=2E It is reasonable to expect people to follow the rules=2E Most new features should be in Lisp and changes to C code should be in ser= vice of making it possible to put more logic in Lisp=2E > We >routinely let much more easily-spotted blunders slip though=2E The >sheer number of subtleties and factoids you need to keep in mind when >writing safe code in Emacs is already inhumanly large=2E Yes=2E It's hard enough to write C code as it is=2E That's why people need= to write C code with clear and simple bright-line rules on memory safety= =2E For example, instead of thinking about whether this or that function sc= ope Lisp_Object is safe, just ban function scope Lisp_Object static variabl= es generally=2E Much lower cognitive burden this way=2E >We only get away because there are many places where GC cannot happen=2E We also get away with a lot because the old GC is non-moving=2E The things= we get away with are fragile whether or not the old GC being forgiving mak= es them technically safe=2E >Admittedly, with the proliferation of calls into Lisp, there's less >and less of these places each year=2E Yes, which is why it's best to make code GC safe in general=2E Just like w= e don't have to sprinkle the register keyword around anymore, we don't have= to try to get clever and avoid having to gcpro this or that thing=2E Prote= ct all the things=2E Simple and robust=2E
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.
Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 14:48:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 06 09:48:23 2025
Received: from localhost ([127.0.0.1]:37502 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tUoP0-0008KH-QI
for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 09:48:23 -0500
Received: from dancol.org ([2600:3c01:e000:3d8::1]:57250)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1tUoOy-0008K6-9u
for 75322 <at> debbugs.gnu.org; Mon, 06 Jan 2025 09:48:21 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org;
s=x;
h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:
Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=RJhmg6Hyu9C3OwpRN4wq+SeVTTU+t9CeQb6mOEamAfg=; b=DcoIq6ZFTtC9pzIJtv3fmHpmkS
fz4BQjIhcJP0bk0V75WjeFo/+P9rGrjk/dm7xyjAHMs7YSw7uJ1/jPZQMh+b1wLLzOFGScryAp8nP
dOjlNjIkGzwFzleWkvpbbHTDUVw8HkiHPX/nRpOV3ctd96EiNlYTq+Og7SODW+NYxRwjZ+m0C+4UB
OKOqRSkL907hd7sOTbfMA5KNXfDxqXvghtj3NZ/Roa/6VYEJQZjeF/9jLU/9GbksBMNRRydyt4uMv
YDX6QbEqi+3/v9H8SrOBaW/cbq95JJOrqF8bKe83D2I1XcnpubVDZIvuayGppNUxqmoSKitW0fZGx
KxfUpFVQ==;
Received: from 2603-9001-4203-1ab2-1e69-c57e-fb78-2899.inf6.spectrum.com
([2603:9001:4203:1ab2:1e69:c57e:fb78:2899]:32928 helo=localhost)
by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1tUoOp-0002X2-1p;
Mon, 06 Jan 2025 09:48:11 -0500
From: Daniel Colascione <dancol@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
In-Reply-To: <867c786quc.fsf@HIDDEN> (Eli Zaretskii's message of "Mon, 06 Jan
2025 14:59:07 +0200")
References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN>
<m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN>
<m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN>
<m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN>
<m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN>
<m2v7uttkoz.fsf@HIDDEN> <86msg56to8.fsf@HIDDEN>
<m25xmtt9a6.fsf@HIDDEN> <86h66d6pw1.fsf@HIDDEN>
<4B76EB57-AA29-40BC-8361-0906E00A3578@HIDDEN>
<867c786quc.fsf@HIDDEN>
User-Agent: mu4e 1.12.8; emacs 31.0.50
Date: Mon, 06 Jan 2025 09:48:09 -0500
Message-ID: <87wmf8t2vq.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 75322
Cc: gerd.moellmann@HIDDEN, pipcet@HIDDEN, 75322 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Eli Zaretskii <eliz@HIDDEN> writes:
>> Date: Sun, 05 Jan 2025 16:15:47 -0500
>> From: Daniel Colascione <dancol@HIDDEN>
>> CC: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org
>>
>> > . an automatic variable
>> > . a static variable that is protected by someone
>> > . a global variable that is protected by someone
>> > . a result of dereferencing a pointer that is somehow protected
>> >
>> >etc. etc., where "protected by someone" means that it is a descendant
>> >of some staticpro, or of some root, or...
>>
>> Well, yeah. Every other GC program does this. Emacs can too. There's
>> no great burden: all Lisp objects get traced
>> automatically. Everything on the stack or in a register gets traced
>> automatically, and, because the scanning is conservative,
>> pinned. You only have to take extra steps to tell the GC about
>> something when you're going out of your way to go around the GC.
>>
>> It's simply not true that to adopt a modern GC every line of code has to change. I wrote a moving GC for Emacs myself years ago. Worked fine. No rewrite.
>
> The opinions in this thread are that changes in the code _are_ needed.
> Maybe that's not a "rewrite" you had in mind, but if we need to make
> such substantial changes in many places, that's a "rewrite" in my
> book.
I wouldn't call it a "rewrite". If auditing the codebase for memory
safety is a "rewrite", I'm a "duck". We're talking about a few hundred
lines of changes at the most. Most of the work is just auditing the
code for problems. We should be grateful Gerd has done this work
already, not "run away from MPS, fast".
>> >And if we cannot prove to ourselves that one of the above happens,
>> >then we'd need to force a copy of the variable to be on the stack?
>> >
>> >Does this sound practical?
>> >
>> >If this is the price of using MPS, and I'm not missing something
>> >obvious, then it sounds like we should run away from MPS, fast.
>> >Because we will sooner or later have to rewrite every single line of
>> >code we ever wrote.
>>
>> No, you do it by adopting a rule that when a function receives a
>> pointer, the caller guarantees the validity of the pointer for the
>> duration of the call. This way, only the level of the stack that
>> spills the array to the heap has to take on the responsibility of
>> keeping the referenced objects alive, and making the spilled array a
>> pointer to the pinned guts of a Lisp vector is an adequate way to
>> do this.
>
> We are talking about code such as this one:
>
> 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;
>
> "Look, ma: no pointers!"
Lisp_Object val, *args2;
In the C programming language, "*" means "pointer".
> The args[] array is fine: it comes from the caller and is valid. The
> problem being discussed here is the args2[] array, in the case where
> SAFE_NALLOCA decides args2[] is too large for the stack and instead
> malloc's it. In that case, args2[] stores on the heap copies of the
> objects in args[] (still no pointers!), and the issue is that when GC
> happens (say, at some point inside Ffind_operation_coding_system), the
> objects in args[] are updated by GC, but their copies in args2[] are
> not.
Each Lisp_Object held across a GC must either:
1) be visible to the GC for precise marking and updating (which is the
case for all references from Lisp object to another as well as
staticpro-protected static storage), or
2) be visible to the GC for conservative marking and pinning instead
of moving, which today means the variable is on the stack.
A Lisp_Object embedded in a block of malloc-heap memory doesn't satisfy
either condition and so is unsafe.
Also, this pattern is perfectly fine:
void
foo()
{
Lisp_Object c = Fcons(...);
bar(&c);
}
void
bar(Lisp_Object* c)
{
eassert(CONSP(c));
Fgarbage_collect();
eassert(CONSP(c));
}
because when bar() gets its pointer, it implicitly assumes that it's
*caller* has followed the rule above, which it has.
The Emacs code already works this way. The changes we're talking about
are not anywhere near as large-scale as what you might have in mind.
> So this code needs to be changed.
The snippet you quoted above can be fixed with a one-liner --- replace
SAFE_NALLOCA with SAFE_ALLOCA_LISP. (We have to fix
SAFE_ALLOCA_LISP_EXTRA to make it safe with the old GC, but that's not a
change that needs to happen at call sites.)
> And if you look around, we have quite a lot of these in many places.
Sounds like Gerd's spent some time hunting them down.
>> "Oh, but won't that kill performance?"
>
> That wasn't my primary bother. The primary bother is the need to
> modify many places. Which is not necessarily a purely mechanical
> refactoring, either. Consider:
>
> static Lisp_Object last_coding;
> Lisp_Object coding = Vcoding_system_for_write;
> [...]
> last_coding = coding;
> call_some_function ();
> if (NILP (last_coding))
> do_something ();
>
> If call_some_function can trigger GC, the value of 'coding' after the
> call is still valid, but the value of 'last_coding' could be garbage
> (unless 'last_coding' is staticpro'd).
Correct. The fix is to move last_coding to file scope and gcpro it.
You can argue that moving this declaration around is not a "mechanical"
fix, but it's straightforward, safe, and makes the code clearer: after
the change, the static storage is at file scope where you can see it,
not buried in a function body.
> We have almost 200 static
> Lisp_Object variables, probably not all of them staticpro'd (8 of them
> inside functions, like the above example, so definitely not
> staticpro'd). So now we need to examine the uses of all of them and
> either staticpro them or do something else (like move the assignment
> to 'last_coding' to after call_some_function).
Changing eight variables from function statics to file statics hardly
seems like a monumental effort. The static-storage global-scope
Lisp_Object variables are probably almost all gcproed already.
Gerd has already gone a long way towards identifying the various problem
spots. In particular, his change to move uses of SAFE_ALLOCA to the
_LISP variant in various places is good and should be applied regardless
of the readiness of the rest of the MPS branch. Even in cases where for
one reason or another the code he's changing is safe under the old GC,
the old code is fragile and can break under modification.
> And we will probably find other usage patterns which trip the same
Yep.
> And the amazing part is not the above, it''s the fact that with all
> that "unsafe" code people are using the branch for production, and
> most of them report a stable Emacs. What does that tell us? that
> most, if not all, of those places are perfectly valid code, and we are
> haunted by the proverbial shadow of a dwarf? Or maybe it just makes
> the job harder, because we now need to identify the places where these
> bad things can _really_ happen, and fix only them? Or something else?
> This is what I'm trying to establish. The problem is not theoretical,
> it's entirely practical: where to steer our efforts of stabilizing the
> branch and preparing it for landing, given the available resources.
There are three reasons we might not see code with dubious adherence to
GC rules cause problems in practice:
1) the dubious code is unsafe only in rare edge cases (who has thousands
of call-process parameters?) or the problems are GC-timing dependent,
2) the dubious code is safe only because all the Lisp values in question
are protected by other references and the old GC is non-moving, and
3) the dubious code is safe only because the only Lisp values stored in
these malloc-heap regions talk about objects that are naturally
immortal, e.g. Qnil, and the GC doesn't move immortal values.
A case of #1 is a memory safety problem. #2 and #3 merely mean we have
fragile code. Sometimes it's hard to tell the difference, which is why
we should fix all three.
A moving GC like MPS imposes more stringent requirements on a program
than a non-moving one does, but the changes needed to make Emacs safe
under a moving GC are not particularly invasive and make the code safer
and more maintainable overall. Most of the changes should be one- or
few-line tweaks.
We're talking about nothing remotely close to a general rewrite.
>> The *existing* code is broken, and you don't see it because we use alloca to allocate on the stack almost all the time.
>
> If we allocate on the stack almost all the time, we will keep
> allocating on the stack almost all the time. But anyway, if you are
> now saying that the code is broken, then a rewrite, and a significant
> one at that, _is_ needed, right?
"Almost" isn't good enough when it comes to memory safety problems and
the security issues they often cause.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 14:07:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 06 09:07:46 2025 Received: from localhost ([127.0.0.1]:37370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUnlh-00066r-NT for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 09:07:46 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44230) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUnle-00066U-AT for 75322 <at> debbugs.gnu.org; Mon, 06 Jan 2025 09:07:44 -0500 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 <eliz@HIDDEN>) id 1tUnlY-0006P6-MQ; Mon, 06 Jan 2025 09:07:36 -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=yQ5r2B2FU8YsTVc31D8H4C1x7PM1fvTh+Qze3BStSvY=; b=dW9OZ1sCQ7rtLe3riIhb WXWSinajVhtuq1W4eu52oU258uRwfRnaAUFFpYoj5imcoTr0v9cr55VlGtPO4Fbgl11dbVuS2FsXv Js7BQ2iCAS6MJ95WJk1SDkJ3dq6d+s2emzsRac0SXDE+W8tt1KJ8kjay5aaAMtOTUveAW5QFKSsuV GaZizupTBEQ0f9a/Rsm6hiJN+Tv+KAEL2N5Nt0wY/IztVriVSoGS8DF554rBtMd2/PDh2u2X0O3At IvJ3+yhsoHgPsMomwk0SvRitLbcm1+IdLE35BuhX6ofc2Hv4/RE7GIlUHecHAUsKBIdWZKUfrkwNu x6+wrjyH9cyQjA==; Date: Mon, 06 Jan 2025 16:07:31 +0200 Message-Id: <86pll0593w.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2sepwsifi.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Mon, 06 Jan 2025 04:57:37 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> <86msg56to8.fsf@HIDDEN> <m25xmtt9a6.fsf@HIDDEN> <86h66d6pw1.fsf@HIDDEN> <m2wmf9rpqv.fsf@HIDDEN> <868qrp6mbs.fsf@HIDDEN> <m2sepwsifi.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org > Date: Mon, 06 Jan 2025 04:57:37 +0100 > > >From my POV: So we're talking about things, you want to make it > concrete, we land in call_process, I explain why SAFE_NALLOCA is unsafe > when used with references even with the old GC, you think references are > on the stack because the parameter args is on stack, and I say no. > > Next thing I get is a rant. It wasn't a rant, it was an honest surprise that we'd need to go to such lengths to accommodate MPS. I still consider the effort to be huge and not very practical, and even if someone volunteers to make all those changes, I'd be petrified to think how many bugs this could introduce on the way. > You don't even say "you're right" or "you're > wrong", so I don't know for sure if you accept my argumentation or not. Sorry for my style, but I usually try not to say things that add nothing to the discussion.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 13:26:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 06 08:26:45 2025 Received: from localhost ([127.0.0.1]:37285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUn7w-00043D-QZ for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 08:26:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39584) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUn7t-00042s-Hs for 75322 <at> debbugs.gnu.org; Mon, 06 Jan 2025 08:26:38 -0500 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 <eliz@HIDDEN>) id 1tUn7m-0007Ih-SY; Mon, 06 Jan 2025 08:26:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=gr6nPRWqV+tgpKxpiDemihrTKHZv3r/9zu4Nrf37XSI=; b=DfEHN0NkclSb 3PX6c/dfn50Q/HGlLNPS/Fz83em9z0qmQLq1PTv4f8nTJJk3D7SeUz2DVTnwnHZAjmtnAaQh3w4TG SoJTt+LBYdQP2Gyp2+a6VLnKaCbhx1bRnSjuKL316HlrbK7KuhE9sMd/J5RuxJu7M7Nyj9bf1q7ua o2Ola6KpWXxzIK5lL95d3VHIV1oXkDwEEAtquExNuapb+4TAqDyb1urpdEwy2x8SH+G/RPDCCoWnP zZZZ305dYe09BAl5zIP6xNFAy054zh9c8rsuksHhRTW/jYEJr8Y9lXCnCZ5U2ERSj/gljWJH0/2xa Sng/RzUoTODNIEe9u/BVeg==; Date: Mon, 06 Jan 2025 15:26:15 +0200 Message-Id: <86v7us5b0o.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Daniel Colascione <dancol@HIDDEN> In-Reply-To: <87sepwvo04.fsf@HIDDEN> (message from Daniel Colascione on Sun, 05 Jan 2025 18:28:59 -0500) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> <225431A0-98C1-4F95-B290-AB86F5379030@HIDDEN> <87sepwvo04.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: gerd.moellmann@HIDDEN, pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Daniel Colascione <dancol@HIDDEN> > Cc: gerd.moellmann@HIDDEN, eliz@HIDDEN, pipcet@HIDDEN > Date: Sun, 05 Jan 2025 18:28:59 -0500 > > Daniel Colascione <dancol@HIDDEN> writes: > > Here's a demonstration of the problem. Run ./emacs -batch -Q --eval > '(acos 0)'. If you leave demo_crash to true, Emacs will abort quickly > after we detect a use-after-free. If you set demo_crash to false, Emacs > will run the loop all day. It is a well-known fact that inserting Fgarbage_collect in various random places can cause bugs. But expecting every Emacs C-level hacker to write code that will endure such testing is impractical. We routinely let much more easily-spotted blunders slip though. The sheer number of subtleties and factoids you need to keep in mind when writing safe code in Emacs is already inhumanly large. We only get away because there are many places where GC cannot happen. Admittedly, with the proliferation of calls into Lisp, there's less and less of these places each year.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.
Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 12:59:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 06 07:59:22 2025
Received: from localhost ([127.0.0.1]:37174 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tUmhT-0002Tk-17
for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 07:59:22 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:53720)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUmhR-0002TX-0A
for 75322 <at> debbugs.gnu.org; Mon, 06 Jan 2025 07:59:17 -0500
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 <eliz@HIDDEN>)
id 1tUmhL-0001e4-85; Mon, 06 Jan 2025 07:59:11 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=aOjweXmfgueQjISw82b0XHL5Wa4qyoKsxsaSHjNXdP4=; b=ISGSwZWiH8mn
wVPJH2hCD3/EnTHIL/kKFSl0s/s/0hTtwBrQMMvNLB8Bgj0XeTAFhX/0tcMuHsthGv2XfdnjIWyOZ
BbZq2Y+ShdNP2dhJbarCrWv3J8e3eGvyMd999a/29fQmzjgsE8F8KLkRtDeYsnlUDjKcHqv5CEYVq
yEnhtbn1tXr3yHG5w0WPIPyYuZofptj3dY5bdDLqXzm5xz9mru4PCEpL8gWLW+IzL4xZMGOK8ICFd
axOlrSXm5djchsZNvCJoCxo2mTw7VTNLZpzWH+DpylW5nVKBOq5aBkpzONBZYZp4xlB7XYfbqfKrL
5omF4AMArcwY+jzfDfdADQ==;
Date: Mon, 06 Jan 2025 14:59:07 +0200
Message-Id: <867c786quc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Daniel Colascione <dancol@HIDDEN>
In-Reply-To: <4B76EB57-AA29-40BC-8361-0906E00A3578@HIDDEN> (message from
Daniel Colascione on Sun, 05 Jan 2025 16:15:47 -0500)
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN>
<m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN>
<m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN>
<m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN>
<m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN>
<m2v7uttkoz.fsf@HIDDEN> <86msg56to8.fsf@HIDDEN>
<m25xmtt9a6.fsf@HIDDEN> <86h66d6pw1.fsf@HIDDEN>
<4B76EB57-AA29-40BC-8361-0906E00A3578@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75322
Cc: gerd.moellmann@HIDDEN, pipcet@HIDDEN, 75322 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Sun, 05 Jan 2025 16:15:47 -0500
> From: Daniel Colascione <dancol@HIDDEN>
> CC: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org
>
> > . an automatic variable
> > . a static variable that is protected by someone
> > . a global variable that is protected by someone
> > . a result of dereferencing a pointer that is somehow protected
> >
> >etc. etc., where "protected by someone" means that it is a descendant
> >of some staticpro, or of some root, or...
>
> Well, yeah. Every other GC program does this. Emacs can too. There's no great burden: all Lisp objects get traced automatically. Everything on the stack or in a register gets traced automatically, and, because the scanning is conservative, pinned. You only have to take extra steps to tell the GC about something when you're going out of your way to go around the GC.
>
> It's simply not true that to adopt a modern GC every line of code has to change. I wrote a moving GC for Emacs myself years ago. Worked fine. No rewrite.
The opinions in this thread are that changes in the code _are_ needed.
Maybe that's not a "rewrite" you had in mind, but if we need to make
such substantial changes in many places, that's a "rewrite" in my
book.
> >And if we cannot prove to ourselves that one of the above happens,
> >then we'd need to force a copy of the variable to be on the stack?
> >
> >Does this sound practical?
> >
> >If this is the price of using MPS, and I'm not missing something
> >obvious, then it sounds like we should run away from MPS, fast.
> >Because we will sooner or later have to rewrite every single line of
> >code we ever wrote.
>
> No, you do it by adopting a rule that when a function receives a pointer, the caller guarantees the validity of the pointer for the duration of the call. This way, only the level of the stack that spills the array to the heap has to take on the responsibility of keeping the referenced objects alive, and making the spilled array a pointer to the pinned guts of a Lisp vector is an adequate way to do this.
We are talking about code such as this one:
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;
"Look, ma: no pointers!"
The args[] array is fine: it comes from the caller and is valid. The
problem being discussed here is the args2[] array, in the case where
SAFE_NALLOCA decides args2[] is too large for the stack and instead
malloc's it. In that case, args2[] stores on the heap copies of the
objects in args[] (still no pointers!), and the issue is that when GC
happens (say, at some point inside Ffind_operation_coding_system), the
objects in args[] are updated by GC, but their copies in args2[] are
not.
So this code needs to be changed.
And if you look around, we have quite a lot of these in many places.
> "Oh, but won't that kill performance?"
That wasn't my primary bother. The primary bother is the need to
modify many places. Which is not necessarily a purely mechanical
refactoring, either. Consider:
static Lisp_Object last_coding;
Lisp_Object coding = Vcoding_system_for_write;
[...]
last_coding = coding;
call_some_function ();
if (NILP (last_coding))
do_something ();
If call_some_function can trigger GC, the value of 'coding' after the
call is still valid, but the value of 'last_coding' could be garbage
(unless 'last_coding' is staticpro'd). We have almost 200 static
Lisp_Object variables, probably not all of them staticpro'd (8 of them
inside functions, like the above example, so definitely not
staticpro'd). So now we need to examine the uses of all of them and
either staticpro them or do something else (like move the assignment
to 'last_coding' to after call_some_function).
And we will probably find other usage patterns which trip the same
wire.
And the amazing part is not the above, it''s the fact that with all
that "unsafe" code people are using the branch for production, and
most of them report a stable Emacs. What does that tell us? that
most, if not all, of those places are perfectly valid code, and we are
haunted by the proverbial shadow of a dwarf? Or maybe it just makes
the job harder, because we now need to identify the places where these
bad things can _really_ happen, and fix only them? Or something else?
This is what I'm trying to establish. The problem is not theoretical,
it's entirely practical: where to steer our efforts of stabilizing the
branch and preparing it for landing, given the available resources.
> The *existing* code is broken, and you don't see it because we use alloca to allocate on the stack almost all the time.
If we allocate on the stack almost all the time, we will keep
allocating on the stack almost all the time. But anyway, if you are
now saying that the code is broken, then a rewrite, and a significant
one at that, _is_ needed, right?
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.
Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 08:25:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 06 03:25:38 2025
Received: from localhost ([127.0.0.1]:36584 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tUiQc-0005mG-87
for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 03:25:38 -0500
Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:54562)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>)
id 1tUiQY-0005m6-9k
for 75322 <at> debbugs.gnu.org; Mon, 06 Jan 2025 03:25:36 -0500
Received: by mail-wr1-x42e.google.com with SMTP id
ffacd0b85a97d-3863494591bso7237433f8f.1
for <75322 <at> debbugs.gnu.org>; Mon, 06 Jan 2025 00:25:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1736151933; x=1736756733; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=SJqL5Sz7eNyBHzK9QWLMMdGJMRNwz+tZ12JWVRM+h/U=;
b=mCbinAG0a2sudrebHWD9gmU4tCHUQgYA43J7/W095cgtNni1hqdigz2a1Fize3zpgh
GxP2y4mLEPEjf2+/ispmYjW9P56p/MYL2QcBrTaJ31x6GDqj+T+PdW6fXKoUOc2cBg6M
Vx/yMk/xvcFUJtnR1IRdkv7KqnFYlH74IB3Kw/s2iRqdzVyIAx62pwzQlzcmuYEzzmYc
Ei8qi71NvrWjUVnF6utt4ULmfqpf9HaRtrpXt+3msQtJ2y8EMQf7F0Sde1QKYI+RmdZa
lvQLwEDGDqqYsiJY1/iiISEhPH+F9NonJbnd2gglNcRbWEdju6r/NZCv2Io4sAxwrbKp
wxFQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1736151933; x=1736756733;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
:to:cc:subject:date:message-id:reply-to;
bh=SJqL5Sz7eNyBHzK9QWLMMdGJMRNwz+tZ12JWVRM+h/U=;
b=BLdcMD9oEc0b8kJQWvgygbQx89lz3Evjin51+0JQZYCGP3yeApzpENrrRicQEAsO2N
ffFVyotRTEOEJ976w7heIZslhxkAY7onZAQDv4d06w9MUC+md8BssC9q6zoKkiRtZ6iz
yeJ4OmKUZGioTJjKmw1vUbNwXUsyUa0jwQlvGc1zubqMqkccF6BZ5Pih3DfYvXS4oQrD
O3qpQdgDD8A+Iof4Kx4tY+INSa5KFn4bhVlenIslkSNMR1f+Gp1orpA7O1Kx/VthZcKP
4He5lsbg8gfKxoTrmgbZpa1JEsMhaQL3Fm9yRrK5wCHof1QsQoDCq6VQFWsBmHTkl1J/
CCvQ==
X-Forwarded-Encrypted: i=1;
AJvYcCWjrHUHMQBiHT+JDSKv3Yx6+IYj0WYEq1ept45eacLkTbOL1J4h22wqFU38M6ifwrqainWKRg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwZ37/hkKbh7yEgtWRSpOtbUIgNujarqs3e057V8R+WNQzx2n6e
DY6SOvQX+1nMgN9LV3q49pi3/IINynj4dh1Twx5fCViW4Md46k3VbUirgw==
X-Gm-Gg: ASbGncu2fnQdfE6UetXSZk7iJ7tF2b66jZpNwKS0xrMn16lRsCHw5nPLpaoeufD5pgn
38KzsY5JhEq3zZ3KMjXTgk5qkZaOgZS7mbKuToEcf8IlXR0oEFYDxz2oEkBYu6ghqVSqXPgb9uZ
L4lX8ckUybp7gUWBLPX6IWMlhkTHVkYsHal+KAz+tAeXRZLxsOjUJdw3M9GZaOM25pFFB50oGp9
HDZDu9N7nN7VqwawxLnVWxKQ2qI0iAofkkpvAKDW0I7aHuUmNd3mPnGY4SDQdVrNyFpG6Ho9aEB
PzMOg4QxCGzXq9WAOC4iHGIsbUgHryViCC1/IBpWdgLVW7gLnUHiyEo7baeZEW9JBA==
X-Google-Smtp-Source: AGHT+IFXLV1puM+c1iEh2IAOYrCXgROrNrWXuIaXGFJZhaiy6pTQceSJzsKMxHW5AnHy2wUMVgFx/w==
X-Received: by 2002:a5d:5e09:0:b0:385:e38f:8cc with SMTP id
ffacd0b85a97d-38a223ffa1emr46784474f8f.38.1736151932487;
Mon, 06 Jan 2025 00:25:32 -0800 (PST)
Received: from pro2 (p200300e0b74e69004d937c306cf91eca.dip0.t-ipconnect.de.
[2003:e0:b74e:6900:4d93:7c30:6cf9:1eca])
by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-38a1c8acabbsm46945203f8f.93.2025.01.06.00.25.31
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 06 Jan 2025 00:25:32 -0800 (PST)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
In-Reply-To: <m2sepwsifi.fsf@HIDDEN> ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?=
=?utf-8?Q?s?= message of "Mon, 06 Jan 2025 04:57:37 +0100")
References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN>
<m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN>
<m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN>
<m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN>
<m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN>
<m2v7uttkoz.fsf@HIDDEN> <86msg56to8.fsf@HIDDEN>
<m25xmtt9a6.fsf@HIDDEN> <86h66d6pw1.fsf@HIDDEN>
<m2wmf9rpqv.fsf@HIDDEN> <868qrp6mbs.fsf@HIDDEN>
<m2sepwsifi.fsf@HIDDEN>
Date: Mon, 06 Jan 2025 09:25:31 +0100
Message-ID: <m2zfk4qrgk.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 75322
Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
> Eli Zaretskii <eliz@HIDDEN> writes:
>
>>> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN>
>>> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org
>>> Date: Sun, 05 Jan 2025 21:04:56 +0100
>>>=20
>>> Eli Zaretskii <eliz@HIDDEN> writes:
>>>=20
>>> > How can we possibly make sure this works reliably and safely?? For
>>> > each variable we have in every function, we will need to analyze
>>> > whether the variable is
>>> >
>>> > . an automatic variable
>>> > . a static variable that is protected by someone
>>> > . a global variable that is protected by someone
>>> > . a result of dereferencing a pointer that is somehow protected
>>> >
>>> > etc. etc., where "protected by someone" means that it is a descendant
>>> > of some staticpro, or of some root, or...
>>> >
>>> > And if we cannot prove to ourselves that one of the above happens,
>>> > then we'd need to force a copy of the variable to be on the stack?
>>> >
>>> > Does this sound practical?
>>> >
>>> > If this is the price of using MPS, and I'm not missing something
>>> > obvious, then it sounds like we should run away from MPS, fast.
>>> > Because we will sooner or later have to rewrite every single line of
>>> > code we ever wrote.
>>>=20
>>> I'm bowing out again. It's not worth it.
>>
>> I don't understand why? I need to understand the implications to be
>> able to make decisions, which are part of my job. So I ask questions,
>> and I'm grateful for your answers, which clarify the issues for me.
>> That I sometimes sound overwhelmed by the implications shouldn't be
>> held against me, it's just a normal human reaction, nothing more.
>
> I don't hold that against you, that's why I'm trying to answer
> questions, write stuff up, and so on, but for me your reply before this
> one was a leaf node in the thread.
>
>> From my POV: So we're talking about things, you want to make it
> concrete, we land in call_process, I explain why SAFE_NALLOCA is unsafe
> when used with references even with the old GC, you think references are
> on the stack because the parameter args is on stack, and I say no.
>
> Next thing I get is a rant. You don't even say "you're right" or "you're
> wrong", so I don't know for sure if you accept my argumentation or not.
> Instead, you write something that came across here as "unreasonable,
> can't be true, we have to change every line of code, let's run from
> MPS".
>
> What should I reply to that? Nothing of course.
>
>> If I somehow sound impolite, I apologize.
>
> No worries about politeness. It wasn't impolite, and I'm not very
> sensible anyway.
Not being sensible is true also, but s/sensible/sensitive/ :-)
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.
Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 06:26:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Jan 06 01:26:30 2025
Received: from localhost ([127.0.0.1]:36459 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tUgZJ-0008Td-RM
for submit <at> debbugs.gnu.org; Mon, 06 Jan 2025 01:26:30 -0500
Received: from mail-wr1-x42c.google.com ([2a00:1450:4864:20::42c]:55726)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>)
id 1tUgZF-0008TO-PO
for 75322 <at> debbugs.gnu.org; Mon, 06 Jan 2025 01:26:27 -0500
Received: by mail-wr1-x42c.google.com with SMTP id
ffacd0b85a97d-3862d6d5765so8208397f8f.3
for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 22:26:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1736144779; x=1736749579; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=PYaspd3+zngJW0bNT31BBY4NRcnACBSoO57KfZ+ZoaM=;
b=hpZIYNMqaPAAsvS1fEkNQ4PhZ+O1LeGx5iTDvTjmwuqD0fcKcOlW/cBBzyr86dFh/B
ot8SSc7/DIWXs6evJZP0ErXVgGf66q4Yb7kvhzPt71JJBg8xoBJImm3kOtNH7jGybCvA
CXAT3M0QxhzOVghPFfWvYg5CEfMf+oxfr607D/CDBn4m8SCXMgc8X5yCGlZus54jTxCk
9gEPVD2bDkFDMuo5avoC0MBC12hnuXVUkIVKxnmMLuKCc6qt4dUmgaohXZGWRywt/D9k
SvNkPCxxwFmm9+1FURyPxsrPJg3VruylMdrCwbPlMV0QMNQFnslwRxu/Y9DERRKa8tVA
2xVQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1736144779; x=1736749579;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
:to:cc:subject:date:message-id:reply-to;
bh=PYaspd3+zngJW0bNT31BBY4NRcnACBSoO57KfZ+ZoaM=;
b=i9H4B31i47fiz2vVk0GunTwt3mMCQCDPW/nzxgugEUgM2FPxGCfq/DRBn118VJld28
+0u870WZhoFke09zMzi+uyHRpyM9onjK0o3QDVNq4QcNb1/XNOudmKBEboCYlrQAtL9q
VyXB9hNt3qw6xTrR1JZUKSrfdlpteHE26CAxEoLLnizt7P2R5yaG/y1HsSqC5jwMBy4J
RAwHgumXxG9GyEEiazM6FsfMFQUzq7mY0aFb+UOOi621c0+nilwp1auDrKw1D+gMU4JO
2+umqM9PFO3XqcN9p8zxpVP+XQaO4MpK/Rl/+NUvWY9l0+me/Tmrxix6t+l8k1Wt+iIx
nHlw==
X-Forwarded-Encrypted: i=1;
AJvYcCXStxBuKc0ZRvbIqJUJjwALxV/ahUGfOKZdxWxgquoHqVHNAHz/whyul7uCr09mxej/Apt/FQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzYvySjCckEzU2Poh7lKl6TRjdJHNZDOyiTLpm4WGIKgdDersdU
KndatxLmoRjXrE7Eve0QNQKSeLnvlAtWcSFlneGcZ59toM8QIXeymRIqfA==
X-Gm-Gg: ASbGncuNVTqLZAzXbTPiU13rLIFJZWn7KRo9IVp5vchMTPuM38X442gbmw4TOzwSv6b
JFf/6IRku2W9wL5Sm3kwdFQP5/EQQ5UFu12H4qhILtQ3X9QnUzNBPLgBing7n2EfKNar4OIX944
fWLs4eQlUbi+q1CpJWjUV4PlVoM+RXNc+qgnsXlb/QpYypOCwEoI1P76lL4XgSV/nB0otbIbLLb
16lMjEljNg7tGcQF0nxoGKFbIg4JZbTSNsH456ITH2e97gyNl5ow98RtbCjVTomVI2gyEU+SFDr
O1qpkfQlRpiyl8fK/8knFn4rCDNbi0hUR+JmWjWuvCFV152jKLyGvhU0HfPJ
X-Google-Smtp-Source: AGHT+IGZI7UX/WlVXc9egYYBQ6ETs6PsaEXICqQwJkjUiypRFEPmWfQ6ZZPENhebXJAJLc/ChYIEAw==
X-Received: by 2002:a05:6000:4024:b0:385:f6b9:e750 with SMTP id
ffacd0b85a97d-38a221f31a9mr40483453f8f.9.1736144779223;
Sun, 05 Jan 2025 22:26:19 -0800 (PST)
Received: from pro2 (p200300e0b74e69004d937c306cf91eca.dip0.t-ipconnect.de.
[2003:e0:b74e:6900:4d93:7c30:6cf9:1eca])
by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-38a1c828e3fsm47627343f8f.5.2025.01.05.22.26.16
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 05 Jan 2025 22:26:18 -0800 (PST)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
In-Reply-To: <m2sepxv90i.fsf@HIDDEN> ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?=
=?utf-8?Q?s?= message of "Sun, 05 Jan 2025 11:40:29 +0100")
References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN>
<865xmtaeh9.fsf@HIDDEN> <m21pxhwu4a.fsf@HIDDEN>
<86r05h8s9d.fsf@HIDDEN> <m2sepxv90i.fsf@HIDDEN>
Date: Mon, 06 Jan 2025 07:26:16 +0100
Message-ID: <m25xmssbjr.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 75322
Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
> Eli Zaretskii <eliz@HIDDEN> writes:
>
>>> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN>
>>> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org
>>> Date: Sun, 05 Jan 2025 09:19:17 +0100
>>>=20
>>> I'd grep for SAFE_NALLOCA, and for each occurrence, see what is stored
>>> in the memory allocated.
>>
>> Is only SAFE_NALLOCA a potential problem? What about the other
>> members of the SAFE_*ALLOC* family?
>
> Haven't checked others yet. I have that on my todo list now.
Checked SAFE_ALLOCA now, and it seems not to be used for holding
references anywhere.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 04:23:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 23:23:17 2025 Received: from localhost ([127.0.0.1]:36326 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUee5-0001yx-BN for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 23:23:17 -0500 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:58500) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUee2-0001yn-J5 for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 23:23:15 -0500 Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-43634b570c1so99669035e9.0 for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 20:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736137393; x=1736742193; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=4CQdrc3rwuCL3fqFk6Dwu1f7zlF/gzN7Ovv+KVm/ssc=; b=O/HmHKv1//y3w59azcTD+JNUWys5r4M9bxRLUO4r5abf2YpgTXCOw+fh6hf6/M8uW2 nZWHcHWcolDXJcxe8vtHxRaVDwBT10qbf+FNbQ6cLq4zIMW1xnH5C84CxSUTc0Cz+t5U zT78sO7OHZjr7Yi1gQOGP+y3HvwM+Abe7ZDJjRU+01+B5SC94vHVsnmsh+uh9AwbjC9G 8jwcnh2fuQADlMAgSNjaemrdkjDXnwcSOmUOtJU5DSAVsXy/SGRH1UtSeHRHaBAk0Xlt yTuzvm6y+dd45NrBkKw0Uh/r48T/6Bj05FsBYBsTNJZNX+IeZk6iw93cVDxkvpWsEylZ NdjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736137393; x=1736742193; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4CQdrc3rwuCL3fqFk6Dwu1f7zlF/gzN7Ovv+KVm/ssc=; b=NWGJhRQd7bjqWFopcOxhWzrPS9WiR3yDu/CmDhWM1Ybb/lbTl69jzy9GbEcPlZ2FvV IZkUjPjwhdkvW533EvPmCw/UTCHaK/4egsqv80u0Bmrk+SOOIxBzy3rrt9YtOo5JCoTy 8N48aASLpAy6luUF94atW5Ye5vUtgk/TJfOWIdBEABd7Hvkg27lVrAgUfeFttG0VixF/ 5V8oUCnUFvfmBNSr7dxbQ5ByFyVPLWCS+nLyjP2yaJMUHNSrJESiACSrXV0ati5L8W9s 0EjcI6poNbbNSn8fL+fJD5mPC0PxZNpx83oZ7SsNH6cxi7cQQE7L1kJ/5IBRbF2kVqQC EKDQ== X-Forwarded-Encrypted: i=1; AJvYcCWXsDH9eLvp22u6at1jVa5gBj9ysNtHb+YXPyYovWDO5BP+fIoIfNXt8c2jxrJeEWY2j5n3Pg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyD/RskfO0CEkdu2sfZcTie+2kNwBqV22MJiNE9dyA6PWM8z7ff eNMlwayS0aUKyQLJZiAE7kST8Fw1Bbm+HHhNA70cMs5h7/nr3xwEJilT4g== X-Gm-Gg: ASbGnctwiRu9n/x5m3/8sr/okNdKJizfBevekr4ka7zjfwRO4YAYSvjQ/GoJ21zasM9 mVxNtap3gfLvH1j/Xcig2GYRoR9tGR4gYVt+gtH1sWakRXDOESBy/SFkdnkZiJ3UZx70eCi8hkQ MvoOVxNyWEB7vxbDyFc3M6vn1+lomcSU5a0Rj2Iq/Plmky2ikhJiXqZAWTB+GQoPdiiF/pYb0w4 0OFET3Rx5rJlypv2jWMGtKe9CuJewxoWuWZGIZ4XMds1fs+ALrV9ApVGJeuld8GSBtQAka0+Cpk oiOundrtNe3OQvbTUpk8FubgM4SmTRG1H0prrMw2o6NVJNC0YirOvFDnNoyx X-Google-Smtp-Source: AGHT+IE72+hy/vU9kAv5ZJtfm7Sj0jU/ftyw7J6HT2DlkIsslbvXbSepmPcCu+YWkqxo6RrUD9IXBQ== X-Received: by 2002:a05:600c:198c:b0:431:3bf9:3ebb with SMTP id 5b1f17b1804b1-43668b5e045mr430522735e9.24.1736137392560; Sun, 05 Jan 2025 20:23:12 -0800 (PST) Received: from pro2 (p200300e0b74e69004d937c306cf91eca.dip0.t-ipconnect.de. [2003:e0:b74e:6900:4d93:7c30:6cf9:1eca]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43656af6aeesm592573675e9.6.2025.01.05.20.23.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 20:23:12 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Daniel Colascione <dancol@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <225431A0-98C1-4F95-B290-AB86F5379030@HIDDEN> (Daniel Colascione's message of "Sun, 05 Jan 2025 16:01:00 -0500") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> <225431A0-98C1-4F95-B290-AB86F5379030@HIDDEN> Date: Mon, 06 Jan 2025 05:23:10 +0100 Message-ID: <m2ikqssh8x.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, bug-gnu-emacs@HIDDEN, 75322 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Daniel Colascione <dancol@HIDDEN> writes: >>If it's that, it's basically the same in the old GC. For example, when >>marking the C stack, we must recognize both pointers to Lisp_Cons and >>Lisp_Objects that look like conses, which contain such a pointer. > > And a third case: interior pointers. A native pointer to a Lisp object > isn't necessarily pointing to the start of that object. Right. Thanks for the backup, BTW :-).
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 6 Jan 2025 04:23:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 23:23:25 2025 Received: from localhost ([127.0.0.1]:36329 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUeeC-0001zI-NC for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 23:23:25 -0500 Received: from lists.gnu.org ([2001:470:142::17]:34696) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUeeA-0001yw-JH for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 23:23:23 -0500 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 <gerd.moellmann@HIDDEN>) id 1tUee4-0002JV-Rx for bug-gnu-emacs@HIDDEN; Sun, 05 Jan 2025 23:23:16 -0500 Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUee3-0006fW-BG; Sun, 05 Jan 2025 23:23:16 -0500 Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-436281c8a38so99540845e9.3; Sun, 05 Jan 2025 20:23:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736137393; x=1736742193; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=4CQdrc3rwuCL3fqFk6Dwu1f7zlF/gzN7Ovv+KVm/ssc=; b=BdaD+blTcLhWmjyQ1scCX8AbQL+q3Zq71WNbhQ3uHnisPrsH9giO2YWYSYQnSdkHA6 ZSeWIhY3SCLSP5G3q+GB5ecr3OEYR+C7Xzwyvek5TnwvgSV3OALKDyIn7rUHActRZKFM JDJXgEwlghfZjQVmOKjysES+YIpp5Egby598FbYYS7n1B1dB2wDx+/GBb7loZRh/mznP JeopbNGUa8zDMwlU9zA3e8I4pTVMcckWodnQFYqwJDY+y0dJpR38cLmKlg8C+qLTQmB/ ds+xMiI9yEzunUkQ7uOiPcqYCiA5g8pFTU8aKGxaizVIklyzoyAcqzF1Aiy/loM2DVKU NECg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736137393; x=1736742193; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4CQdrc3rwuCL3fqFk6Dwu1f7zlF/gzN7Ovv+KVm/ssc=; b=OirxKT3yiDX/hJtNG4SKvMg4rghj+mx+4Ie8IrdZATRtgp1JYGZCxdZcRDesm61vgf Yvcr3vie9WyY8UoDPhtEN4vKaGY84/7BKElyjEoEPRlZ83L67DWa8EIY+bgEtcSvE5dr Ev2UEy2hPyKVkUCQMxQ0HNbPwLHsTLNzyjbge2/5ag1eHSGusI56RwFa8+aegBFuuBxR av/mJSh4HbIDyA69j4MFvzDo1hd1Qjz8ASFA5PMISwn5gdt+RdUFh7QmpN8x0/y983ik CvFM9nxfsddfq8WEiPSEftvS8BoBXaG/+CrOE2dBCsH82f8vOCZ4Rp4I2YAIp08elPKH e5iw== X-Forwarded-Encrypted: i=1; AJvYcCVnx7y05wzS0GczGRWNF5mEbeNvjiozNrR1tyl12ioJNY5wx4DNFZxsHzggJD2SvgRkhBzm@HIDDEN X-Gm-Message-State: AOJu0YxpIMesUoe4kJ0Yzl4S/EuLXXzVU42xSvOBc1GbWIIjPLlOGBHD SPt9n1tICc22tgFyt+0JjzGw5uGeCLjigjalaj381JJmLbJDo45gMNCzYg== X-Gm-Gg: ASbGncsU9u8JpgldeViH9P6lAGnZ2udhGed7CQzuQj2JnXiUpRR31JsXnH1JK49YxWw sdTf6eYFIOQk1HslCdmT0Lq2Dnu436l+Nhy752xf/kKsHvUJuPN1QESYbXP4mXOsKANLO78enfx 1crSey1aDeSJr7oZtknoA81RuXRH5ezydNY61C5+A52GYK+ySAugoPvxxQ65pSTCGSKkicIdjJP iL9t5V/v+dvbnbs3xfnNji/vOOXbrofe9EohAp1KsZyubyIqPUp6hpIMAGNV5T6GfCDg+Kvat6H jSsp3Dj4znQOKvV2dxFWYgVp7Ctgw+T1KpmH0l88H7gDkonoz1dBFW1ZKa+q X-Google-Smtp-Source: AGHT+IE72+hy/vU9kAv5ZJtfm7Sj0jU/ftyw7J6HT2DlkIsslbvXbSepmPcCu+YWkqxo6RrUD9IXBQ== X-Received: by 2002:a05:600c:198c:b0:431:3bf9:3ebb with SMTP id 5b1f17b1804b1-43668b5e045mr430522735e9.24.1736137392560; Sun, 05 Jan 2025 20:23:12 -0800 (PST) Received: from pro2 (p200300e0b74e69004d937c306cf91eca.dip0.t-ipconnect.de. [2003:e0:b74e:6900:4d93:7c30:6cf9:1eca]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43656af6aeesm592573675e9.6.2025.01.05.20.23.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 20:23:12 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Daniel Colascione <dancol@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <225431A0-98C1-4F95-B290-AB86F5379030@HIDDEN> (Daniel Colascione's message of "Sun, 05 Jan 2025 16:01:00 -0500") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> <225431A0-98C1-4F95-B290-AB86F5379030@HIDDEN> Date: Mon, 06 Jan 2025 05:23:10 +0100 Message-ID: <m2ikqssh8x.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::336; envelope-from=gerd.moellmann@HIDDEN; helo=mail-wm1-x336.google.com 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_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit Cc: pipcet@HIDDEN, bug-gnu-emacs@HIDDEN, 75322 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN> X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.0 (/) Daniel Colascione <dancol@HIDDEN> writes: >>If it's that, it's basically the same in the old GC. For example, when >>marking the C stack, we must recognize both pointers to Lisp_Cons and >>Lisp_Objects that look like conses, which contain such a pointer. > > And a third case: interior pointers. A native pointer to a Lisp object > isn't necessarily pointing to the start of that object. Right. Thanks for the backup, BTW :-).
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 6 Jan 2025 03:57:50 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 22:57:50 2025 Received: from localhost ([127.0.0.1]:36292 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUeFR-0000lU-GM for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 22:57:49 -0500 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:54346) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUeFP-0000lC-Ab for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 22:57:48 -0500 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-436326dcb1cso92268305e9.0 for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 19:57:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736135860; x=1736740660; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=MRqSPXKIp2F2TKT64kLxvo31zs8EMXK+tWZZMPquSe4=; b=AjGtZn4s20BEIh7b2oJKdeYHWuZfOuvFFtGx4rcgWu3p4kHWQG+N2sZY9atcaSlj7X rHt7d5rFiGfrlvkjNNnS+IM9CEXoGn5VvlIfmVyafk6sL1YSrei+2+jbN8JteASDSljT tt8rXCOFqBzmICia/jcQmxR8cXnjdxKm9hec3p9VLE0ZQ5s8ZBLVU5O1Cz7413wjfB0Q 1JYvScu5ZUDxuwSaZzjlgAx4XxM5bHky/DJsurLsDJ5MpAjp58VIiBJEG+r5tkXcWrnf 4WAEhKoMkyw5Tis5JvsNbGff7VcX/BhwpqYQtSSDWbg9xpEs1JGwb+F4IyQDY1NZzCuc lWxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736135860; x=1736740660; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=MRqSPXKIp2F2TKT64kLxvo31zs8EMXK+tWZZMPquSe4=; b=wvwV4Yy05wb7S+hsRd9A9go9wbW2Op1oNTA4MhCWoJlCG5sMrySR9U3zJMglk5/jmv Fj5WryPMhmz8iE7Is6kPmD8WueiFmQdRq620aBW5cY2eShym1gDVJIhgvFAwNEB5xBrU ze3JbZQ06k9TEhUYANscvFsKuHCMOoggD8otA0srvx0HkReWR+htSnOgSG95X42+WqGz V9E5D8x9Q2SFUjRAkNhASe2OIOf+9XDkk5HVvjW0v7yosGQOW82NJHPLeOSWfmLaKipM bM6oYozQV05VgEkN5meeoVaXytOfdb6LQ5o4rAXR1+Q9jEXpuI4rCOi7vseCO8UIEWYa aTOg== X-Forwarded-Encrypted: i=1; AJvYcCUcy/iNcAjx89N/wcFf6k7KK3Lu1il8U1j+yxf1dNPw7kB2TAq02EHDtDmOAejuRAibVuQGLg==@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywo2vGsCjjIt0zONKpwxfUUrHCRVMSIrV5+Cx2daM8PNoSMPvu/ XE8omfugOOeEw/hukE6j+UpKa34X4IlCEEw6KPsNWA/Knr0DIeSJtqr0iQ== X-Gm-Gg: ASbGnctgQPM5nRw0I4exF1kXJH6nNKofukRX3FwqCAO/RwAvweHLnsW2uFj0wPTk4qZ s6pIEjQGV3Py8fRAOg1MnNCNsA9csPe+soikSmsjT5CKfUS8q/w3PR9TxqGki968ZH/eCzKjfL5 txNOKilcUGnxgim9FqgmIkNbse0g+jltuU2CYA4GfHrGu6nJqcJGguxcMvn+PhV/amT5H5HVn4G F0FYYcoDj5EzWmaCG80mA8zlphsdu7zq4LXileI5xk/tTT46E/HkKDt/VbF0+FLJPH7hNeJptia tP19MG5NyrcBxTTZtxIr33ezi/w2+YJBdSMcLQipbNIwaP65KsXBsuHclzXW X-Google-Smtp-Source: AGHT+IHp2lCRJXK8MrlrBvQU5XsecNqgrxabMVgKXLHRpby5BwzrOg1xU2rrN/oXsrSzrM5Z+5/BCQ== X-Received: by 2002:a05:600c:4f51:b0:436:51bb:7a52 with SMTP id 5b1f17b1804b1-4366854888fmr410497415e9.7.1736135860245; Sun, 05 Jan 2025 19:57:40 -0800 (PST) Received: from pro2 (p200300e0b74e69004d937c306cf91eca.dip0.t-ipconnect.de. [2003:e0:b74e:6900:4d93:7c30:6cf9:1eca]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4366128a62asm550716565e9.44.2025.01.05.19.57.38 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 19:57:38 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <868qrp6mbs.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 05 Jan 2025 22:24:23 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> <86msg56to8.fsf@HIDDEN> <m25xmtt9a6.fsf@HIDDEN> <86h66d6pw1.fsf@HIDDEN> <m2wmf9rpqv.fsf@HIDDEN> <868qrp6mbs.fsf@HIDDEN> Date: Mon, 06 Jan 2025 04:57:37 +0100 Message-ID: <m2sepwsifi.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org >> Date: Sun, 05 Jan 2025 21:04:56 +0100 >>=20 >> Eli Zaretskii <eliz@HIDDEN> writes: >>=20 >> > How can we possibly make sure this works reliably and safely?? For >> > each variable we have in every function, we will need to analyze >> > whether the variable is >> > >> > . an automatic variable >> > . a static variable that is protected by someone >> > . a global variable that is protected by someone >> > . a result of dereferencing a pointer that is somehow protected >> > >> > etc. etc., where "protected by someone" means that it is a descendant >> > of some staticpro, or of some root, or... >> > >> > And if we cannot prove to ourselves that one of the above happens, >> > then we'd need to force a copy of the variable to be on the stack? >> > >> > Does this sound practical? >> > >> > If this is the price of using MPS, and I'm not missing something >> > obvious, then it sounds like we should run away from MPS, fast. >> > Because we will sooner or later have to rewrite every single line of >> > code we ever wrote. >>=20 >> I'm bowing out again. It's not worth it. > > I don't understand why? I need to understand the implications to be > able to make decisions, which are part of my job. So I ask questions, > and I'm grateful for your answers, which clarify the issues for me. > That I sometimes sound overwhelmed by the implications shouldn't be > held against me, it's just a normal human reaction, nothing more. I don't hold that against you, that's why I'm trying to answer questions, write stuff up, and so on, but for me your reply before this one was a leaf node in the thread. From my POV: So we're talking about things, you want to make it concrete, we land in call_process, I explain why SAFE_NALLOCA is unsafe when used with references even with the old GC, you think references are on the stack because the parameter args is on stack, and I say no. Next thing I get is a rant. You don't even say "you're right" or "you're wrong", so I don't know for sure if you accept my argumentation or not. Instead, you write something that came across here as "unreasonable, can't be true, we have to change every line of code, let's run from MPS". What should I reply to that? Nothing of course. > If I somehow sound impolite, I apologize. No worries about politeness. It wasn't impolite, and I'm not very sensible anyway.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.
Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 23:29:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 18:29:09 2025
Received: from localhost ([127.0.0.1]:35893 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tUa3Q-0003WR-Om
for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 18:29:09 -0500
Received: from dancol.org ([2600:3c01:e000:3d8::1]:44684)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1tUa3N-0003WE-FD
for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 18:29:06 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org;
s=x;
h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:
References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
List-Post:List-Owner:List-Archive;
bh=CY6MM83M+8Y2t/E38eNXGJmZDratcczERmaWgPv7Vu0=; b=LtiUPr6/2XXc80GS2hZKkGLFCG
lGVMmWdkpG9iEcWt7c1fr1mjcNAs47AeRG4N1gQAJ2DLLVr4zfInmGTQKGzxhELpf+66+LCZ7M2rE
Rk/JmOmJxEuALzN6ZjeIK5i3By9ma3+MN/g3owVFTIhPv0GaLVbuRA+iQVnv1IYo4grEQbS6mRzW/
pKfOU7ZKmMB4VShLCHqDr5UV7DBYQum/30/LRvBnNcFsbpWxC8vBXS8i5shvI16+/KLc49EkxKiha
Q1IKiNQ2QrFJbSKQVPmqDxhqJPdAHOLPkhAdomd7R5mJqc0fN9hhhnMCQSB+Hh0iqBPIDFVlwNbaJ
yBmQnPPw==;
Received: from 2603-9001-4203-1ab2-7ab6-aa97-d11e-5f4a.inf6.spectrum.com
([2603:9001:4203:1ab2:7ab6:aa97:d11e:5f4a]:54182 helo=localhost)
by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
(Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1tUa3J-0006ej-2v;
Sun, 05 Jan 2025 18:29:02 -0500
From: Daniel Colascione <dancol@HIDDEN>
To: 75322 <at> debbugs.gnu.org
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
In-Reply-To: <225431A0-98C1-4F95-B290-AB86F5379030@HIDDEN> (Daniel
Colascione's message of "Sun, 05 Jan 2025 16:01:00 -0500")
References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN>
<m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN>
<m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN>
<m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN>
<m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN>
<m2v7uttkoz.fsf@HIDDEN>
<225431A0-98C1-4F95-B290-AB86F5379030@HIDDEN>
User-Agent: mu4e 1.12.8; emacs 31.0.50
Date: Sun, 05 Jan 2025 18:28:59 -0500
Message-ID: <87sepwvo04.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -0.0 (/)
X-Debbugs-Envelope-To: 75322
Cc: gerd.moellmann@HIDDEN, eliz@HIDDEN, pipcet@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Daniel Colascione <dancol@HIDDEN> writes:
> On January 5, 2025 9:11:08 AM EST, "Gerd M=C3=B6llmann"
> <gerd.moellmann@HIDDEN> wrote:
>>Eli Zaretskii <eliz@HIDDEN> writes:
>>
>>>> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN>
>>>> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org
>>>> Date: Sat, 04 Jan 2025 11:20:41 +0100
>>>>=20
>>>> 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.
>>
>>Right. If it doesn't use xmalloc, the references are on the C stack, and
>>both old and new GC handle that by scanning the C stack.
>>
>>> 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?=20=20
>>
>>Yes.
>>
>>> 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] =3D Qcall_process;
>>> for (i =3D 0; i < nargs; i++) args2[i + 1] =3D args[i];
>>> coding_systems =3D Ffind_operation_coding_system (nargs + 1, args2=
);
>>> val =3D 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?
>>
>>Let me first say why I find this unsafe in the old GC, in principle. If
>>we don't assume anything about the objects referenced from args2, then a
>>reference in args2 may well be the only one to some object. In this
>>case, the old GC would sweep it.
>
> Gerd is right. This pattern was never safe.
Here's a demonstration of the problem. Run ./emacs -batch -Q --eval
'(acos 0)'. If you leave demo_crash to true, Emacs will abort quickly
after we detect a use-after-free. If you set demo_crash to false, Emacs
will run the loop all day.
diff --git a/src/floatfns.c b/src/floatfns.c
index 065ae16e885..a95597beef8 100644
--- a/src/floatfns.c
+++ b/src/floatfns.c
@@ -50,6 +50,8 @@ Copyright (C) 1988, 1993-1994, 1999, 2001-2025 Free Softw=
are Foundation,
=20
#include <config.h>
=20
+#include <stdlib.h>
+
#include "lisp.h"
#include "bignum.h"
=20
@@ -86,6 +88,31 @@ DEFUN ("acos", Facos, Sacos, 1, 1, 0,
doc: /* Return the inverse cosine of ARG. */)
(Lisp_Object arg)
{
+ Lisp_Object* args2;
+ unsigned start =3D 12345;
+ unsigned counter =3D start;
+ bool demo_crash =3D true;
+
+ USE_SAFE_ALLOCA;
+
+ SAFE_NALLOCA (args2, 1, 1 + (demo_crash ? MAX_ALLOCA : 0));
+ args2[0] =3D Fcons (make_fixnum (counter),
+ make_fixnum (counter + 1));
+ counter +=3D 2;
+ for (;;)
+ {
+ if (!FIXNUMP (XCAR (args2[0])))
+ emacs_abort ();
+ if (XFIXNUM (XCAR (args2[0])) !=3D 12345)
+ emacs_abort ();
+ Fcons (make_fixnum (counter),
+ make_fixnum (counter + 1));
+ Fgarbage_collect ();
+ fprintf (stderr, ".");
+ fflush (stderr);
+ counter +=3D 2;
+ }
+
double d =3D extract_float (arg);
d =3D acos (d);
return make_float (d);
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 5 Jan 2025 21:16:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 16:16:09 2025 Received: from localhost ([127.0.0.1]:35530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUXyi-0002tV-HA for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 16:16:09 -0500 Received: from lists.gnu.org ([2001:470:142::17]:55786) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1tUXyf-0002sN-UV for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 16:16:06 -0500 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 <dancol@HIDDEN>) id 1tUXyS-0001TI-Cq for bug-gnu-emacs@HIDDEN; Sun, 05 Jan 2025 16:15:53 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <dancol@HIDDEN>) id 1tUXyP-0005wn-60; Sun, 05 Jan 2025 16:15:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=KV23DbTrW4+V5Y9Wjtu8lOz9RWkYlG1d0Q+PmoiBdN4=; b=mrULvfsXBmBsvqqsP4T0ccrqoX a21/KS8wHMJUTnRYnSr9ATXvKa1vUzgZqYhiXagAIL0a6JpthAlvlLKtk4XuJ8K89fWubXftnBmqN H1a0K8ZkNDNTLyZ12Ad8iBX+q8sB9pKt3F5VzmHUrljQ+7E8sLZ+lDJgyiriK+ERKqQP/NAA5w80o adYrHeob49LybqILFRrk1mV4gXW+3mpxZqFpZCvM6u/4Pbl+d1FpFoROvLELlW98sVUVPz9CtKnwN 5yVDgOt6H1PwFVlwVUVOueq71bJOefSgtnnRRYi00d4ua6xezFXoN20ALGURxdqpADcz1chfFu5vQ GbQc+T4g==; Received: from 2603-9001-4203-1ab2-9d33-bea9-4999-a2af.inf6.spectrum.com ([2603:9001:4203:1ab2:9d33:bea9:4999:a2af]:49352 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1tUXyM-00068b-2L; Sun, 05 Jan 2025 16:15:46 -0500 Date: Sun, 05 Jan 2025 16:15:47 -0500 From: Daniel Colascione <dancol@HIDDEN> To: bug-gnu-emacs@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, =?ISO-8859-1?Q?Gerd_M=F6llmann?= <gerd.moellmann@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2375322=3A_SAFE=5FALLOCA_assumed_?= =?US-ASCII?Q?to_root_Lisp=5FObjects/SSDATA=28string=29?= User-Agent: K-9 Mail for Android In-Reply-To: <86h66d6pw1.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> <86msg56to8.fsf@HIDDEN> <m25xmtt9a6.fsf@HIDDEN> <86h66d6pw1.fsf@HIDDEN> Message-ID: <4B76EB57-AA29-40BC-8361-0906E00A3578@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@HIDDEN; helo=dancol.org 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.1 (/) On January 5, 2025 2:07:26 PM EST, Eli Zaretskii <eliz@gnu=2Eorg> wrote: >> From: Gerd M=C3=B6llmann <gerd=2Emoellmann@gmail=2Ecom> >> Cc: pipcet@protonmail=2Ecom, 75322@debbugs=2Egnu=2Eorg >> Date: Sun, 05 Jan 2025 19:17:37 +0100 >>=20 >> Eli Zaretskii <eliz@gnu=2Eorg> writes: >>=20 >> > OK, but in most, if not all of these cases, the objects are reference= d >> > from the stack=2E For example, in the above fragment, the args[] arr= ay >> > is on the stack=2E Right? >>=20 >> That args is a parameter >>=20 >> call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd, >>=20 >> So just from this I see only args itself on the stack, not args[0], >> args[1] and so on=2E I would have to look at all callers to determine >> that=2E Not good enough in my book=2E > >So what, we will now need to copy every args[] into a Lisp vector >created by SAFE_ALLOCA_LISP, or xstrdup all of them, and do it in >each and every function that gets the args[] array, all the way down >to where the array is finally used (because usually we have 3 or 4 >nested levels that pass args[] to one another)? That's insane! > >> > What does it mean in detail "the object may move"? A Lisp object is = a >> > tagged pointer=2E Do you mean the pointer should no point to a >> > different address, i=2Ee=2E the value of a Lisp object as a number sh= ould >> > change to still be valid? =20 >>=20 >> Exactly=2E Unless an ambiguous reference prevents the copying that can >> happen=2E > >How can we possibly make sure this works reliably and safely?? For >each variable we have in every function, we will need to analyze >whether the variable is > > =2E an automatic variable > =2E a static variable that is protected by someone > =2E a global variable that is protected by someone > =2E a result of dereferencing a pointer that is somehow protected > >etc=2E etc=2E, where "protected by someone" means that it is a descendant >of some staticpro, or of some root, or=2E=2E=2E Well, yeah=2E Every other GC program does this=2E Emacs can too=2E There's= no great burden: all Lisp objects get traced automatically=2E Everything o= n the stack or in a register gets traced automatically, and, because the sc= anning is conservative, pinned=2E You only have to take extra steps to tell= the GC about something when you're going out of your way to go around the = GC=2E It's simply not true that to adopt a modern GC every line of code has to c= hange=2E I wrote a moving GC for Emacs myself years ago=2E Worked fine=2E = No rewrite=2E >And if we cannot prove to ourselves that one of the above happens, >then we'd need to force a copy of the variable to be on the stack? > >Does this sound practical? > >If this is the price of using MPS, and I'm not missing something >obvious, then it sounds like we should run away from MPS, fast=2E >Because we will sooner or later have to rewrite every single line of >code we ever wrote=2E No, you do it by adopting a rule that when a function receives a pointer, = the caller guarantees the validity of the pointer for the duration of the c= all=2E This way, only the level of the stack that spills the array to the h= eap has to take on the responsibility of keeping the referenced objects ali= ve, and making the spilled array a pointer to the pinned guts of a Lisp vec= tor is an adequate way to do this=2E=20 "Oh, but won't that kill performance?" In a generational system, allocating small, short-lived objects is actuall= y cheap ---- usually faster than mallloc=2E I don't recall how MPS does it,= but in some garbage collectors, a gen0 allocation of this sort is literall= y just incrementing a pointer=2E Malloc has a substantial cost of its own too=2E Yes, these objects make a gen0 GC happen sooner=2E So what? Young generati= on GC is cheap=2E If you could observe a performance problem, you could sol= ve the reference problem by maintaining a thread local linked list of spill= ed array blocks and teach the GC to scan them, but that's likely overkill= =2E Anyway, every native code program anywhere that uses GC has to care about = lifetimes and references=2E Abandoning MPS doesn't magically make the prob= lem go away=2E The *existing* code is broken, and you don't see it because = we use alloca to allocate on the stack almost all the time=2E=20
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 21:15:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 16:15:57 2025 Received: from localhost ([127.0.0.1]:35526 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUXyW-0002sc-Qb for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 16:15:57 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]:36840) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1tUXyS-0002sK-VJ for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 16:15:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=KV23DbTrW4+V5Y9Wjtu8lOz9RWkYlG1d0Q+PmoiBdN4=; b=mrULvfsXBmBsvqqsP4T0ccrqoX a21/KS8wHMJUTnRYnSr9ATXvKa1vUzgZqYhiXagAIL0a6JpthAlvlLKtk4XuJ8K89fWubXftnBmqN H1a0K8ZkNDNTLyZ12Ad8iBX+q8sB9pKt3F5VzmHUrljQ+7E8sLZ+lDJgyiriK+ERKqQP/NAA5w80o adYrHeob49LybqILFRrk1mV4gXW+3mpxZqFpZCvM6u/4Pbl+d1FpFoROvLELlW98sVUVPz9CtKnwN 5yVDgOt6H1PwFVlwVUVOueq71bJOefSgtnnRRYi00d4ua6xezFXoN20ALGURxdqpADcz1chfFu5vQ GbQc+T4g==; Received: from 2603-9001-4203-1ab2-9d33-bea9-4999-a2af.inf6.spectrum.com ([2603:9001:4203:1ab2:9d33:bea9:4999:a2af]:49352 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1tUXyM-00068b-2L; Sun, 05 Jan 2025 16:15:46 -0500 Date: Sun, 05 Jan 2025 16:15:47 -0500 From: Daniel Colascione <dancol@HIDDEN> To: bug-gnu-emacs@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, =?ISO-8859-1?Q?Gerd_M=F6llmann?= <gerd.moellmann@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2375322=3A_SAFE=5FALLOCA_assumed_?= =?US-ASCII?Q?to_root_Lisp=5FObjects/SSDATA=28string=29?= User-Agent: K-9 Mail for Android In-Reply-To: <86h66d6pw1.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> <86msg56to8.fsf@HIDDEN> <m25xmtt9a6.fsf@HIDDEN> <86h66d6pw1.fsf@HIDDEN> Message-ID: <4B76EB57-AA29-40BC-8361-0906E00A3578@HIDDEN> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On January 5, 2025 2:07:26 PM EST, Eli Zaretskii <eliz@gnu=2Eorg> wrote: >> From: Gerd M=C3=B6llmann <gerd=2Emoellmann@gmail=2Ecom> >> Cc: pipcet@protonmail=2Ecom, 75322@debbugs=2Egnu=2Eorg >> Date: Sun, 05 Jan 2025 19:17:37 +0100 >>=20 >> Eli Zaretskii <eliz@gnu=2Eorg> writes: >>=20 >> > OK, but in most, if not all of these cases, the objects are reference= d >> > from the stack=2E For example, in the above fragment, the args[] arr= ay >> > is on the stack=2E Right? >>=20 >> That args is a parameter >>=20 >> call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd, >>=20 >> So just from this I see only args itself on the stack, not args[0], >> args[1] and so on=2E I would have to look at all callers to determine >> that=2E Not good enough in my book=2E > >So what, we will now need to copy every args[] into a Lisp vector >created by SAFE_ALLOCA_LISP, or xstrdup all of them, and do it in >each and every function that gets the args[] array, all the way down >to where the array is finally used (because usually we have 3 or 4 >nested levels that pass args[] to one another)? That's insane! > >> > What does it mean in detail "the object may move"? A Lisp object is = a >> > tagged pointer=2E Do you mean the pointer should no point to a >> > different address, i=2Ee=2E the value of a Lisp object as a number sh= ould >> > change to still be valid? =20 >>=20 >> Exactly=2E Unless an ambiguous reference prevents the copying that can >> happen=2E > >How can we possibly make sure this works reliably and safely?? For >each variable we have in every function, we will need to analyze >whether the variable is > > =2E an automatic variable > =2E a static variable that is protected by someone > =2E a global variable that is protected by someone > =2E a result of dereferencing a pointer that is somehow protected > >etc=2E etc=2E, where "protected by someone" means that it is a descendant >of some staticpro, or of some root, or=2E=2E=2E Well, yeah=2E Every other GC program does this=2E Emacs can too=2E There's= no great burden: all Lisp objects get traced automatically=2E Everything o= n the stack or in a register gets traced automatically, and, because the sc= anning is conservative, pinned=2E You only have to take extra steps to tell= the GC about something when you're going out of your way to go around the = GC=2E It's simply not true that to adopt a modern GC every line of code has to c= hange=2E I wrote a moving GC for Emacs myself years ago=2E Worked fine=2E = No rewrite=2E >And if we cannot prove to ourselves that one of the above happens, >then we'd need to force a copy of the variable to be on the stack? > >Does this sound practical? > >If this is the price of using MPS, and I'm not missing something >obvious, then it sounds like we should run away from MPS, fast=2E >Because we will sooner or later have to rewrite every single line of >code we ever wrote=2E No, you do it by adopting a rule that when a function receives a pointer, = the caller guarantees the validity of the pointer for the duration of the c= all=2E This way, only the level of the stack that spills the array to the h= eap has to take on the responsibility of keeping the referenced objects ali= ve, and making the spilled array a pointer to the pinned guts of a Lisp vec= tor is an adequate way to do this=2E=20 "Oh, but won't that kill performance?" In a generational system, allocating small, short-lived objects is actuall= y cheap ---- usually faster than mallloc=2E I don't recall how MPS does it,= but in some garbage collectors, a gen0 allocation of this sort is literall= y just incrementing a pointer=2E Malloc has a substantial cost of its own too=2E Yes, these objects make a gen0 GC happen sooner=2E So what? Young generati= on GC is cheap=2E If you could observe a performance problem, you could sol= ve the reference problem by maintaining a thread local linked list of spill= ed array blocks and teach the GC to scan them, but that's likely overkill= =2E Anyway, every native code program anywhere that uses GC has to care about = lifetimes and references=2E Abandoning MPS doesn't magically make the prob= lem go away=2E The *existing* code is broken, and you don't see it because = we use alloca to allocate on the stack almost all the time=2E=20
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 21:01:19 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 16:01:19 2025 Received: from localhost ([127.0.0.1]:35475 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUXkN-0001px-0P for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 16:01:19 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]:36844) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1tUXkF-0001pf-8n for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 16:01:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=m5NHn3Q8s2jgMoBinmO9HnIBkb4UM3ZHvpuYkKiAxvU=; b=oXPoWoyRUGv/E8YJ9QMSqCac99 oraDlWkgHbmOMT6SKAoazsqjXns9Lyi9bRMyqGsK2Vt9sUMUyO424t/gfMEZtQVLE5YFZ8CdSM9DL iBTsxHGG6yZ/6KtS18uk7E/hz3VJuKqg7N32zbjg0mcnxxUrmWRyeQY7TofXh4VzSNstTH9cdKPz7 +RUIbgrALQQhY+CgBx8FiFuzqwa8CVujdBOgH1ZC3SbSx2MrLnxxmyE48Dq5SlnllTLfXrrd1E6rZ THjeTWDYp4jFO6Fkb1nY4Ms+QVs4OvLs+V7/S9TqE9RgGRcBAq3f6J3tzO3FKwR05JUzxMfw2vpri 81m6CDVQ==; Received: from 2603-9001-4203-1ab2-9d33-bea9-4999-a2af.inf6.spectrum.com ([2603:9001:4203:1ab2:9d33:bea9:4999:a2af]:60724 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1tUXk3-00064v-2f; Sun, 05 Jan 2025 16:01:00 -0500 Date: Sun, 05 Jan 2025 16:01:00 -0500 From: Daniel Colascione <dancol@HIDDEN> To: bug-gnu-emacs@HIDDEN, =?ISO-8859-1?Q?Gerd_M=F6llmann?= <gerd.moellmann@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2375322=3A_SAFE=5FALLOCA_assumed_?= =?US-ASCII?Q?to_root_Lisp=5FObjects/SSDATA=28string=29?= User-Agent: K-9 Mail for Android In-Reply-To: <m2v7uttkoz.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> Message-ID: <225431A0-98C1-4F95-B290-AB86F5379030@HIDDEN> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----EN20G1X4PPGH1HCPMNGOMU7GD3X3W0 Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) ------EN20G1X4PPGH1HCPMNGOMU7GD3X3W0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On January 5, 2025 9:11:08 AM EST, "Gerd M=C3=B6llmann" <gerd=2Emoellmann@g= mail=2Ecom> wrote: >Eli Zaretskii <eliz@gnu=2Eorg> writes: > >>> From: Gerd M=C3=B6llmann <gerd=2Emoellmann@gmail=2Ecom> >>> Cc: pipcet@protonmail=2Ecom, 75322@debbugs=2Egnu=2Eorg >>> Date: Sat, 04 Jan 2025 11:20:41 +0100 >>>=20 >>> In callproc=2Ec I found two: call_process and create_temp_file both us= e >>> SAFE_NALLOCA to store Lisp_Objects=2E I think these should be replaces >>> with SAVE_ALLOCA_LISP=2E >> >> 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=2E > >Right=2E If it doesn't use xmalloc, the references are on the C stack, an= d >both old and new GC handle that by scanning the C stack=2E > >> 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? =20 > >Yes=2E > >> 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] =3D Qcall_process; >> for (i =3D 0; i < nargs; i++) args2[i + 1] =3D args[i]; >> coding_systems =3D Ffind_operation_coding_system (nargs + 1, args2= ); >> val =3D CONSP (coding_systems) ? XCDR (coding_systems) : Qnil; >> >> Let's say Ffind_operation_coding_system could trigger GC=2E But we >> never again use the args2[] array after Ffind_operation_coding_system >> returns=2E Is the above still unsafe? If so, could you tell what >> could MPS do during GC to make this unsafe? > >Let me first say why I find this unsafe in the old GC, in principle=2E If >we don't assume anything about the objects referenced from args2, then a >reference in args2 may well be the only one to some object=2E In this >case, the old GC would sweep it=2E Gerd is right=2E This pattern was never safe=2E > Or, the other way 'round, by using >SAFE_NALLOCA we make an assumption=2E And that, from my (GCPRO) POV, need= s >a proof, or better yet some check in code=2E > >Not using arg2 after Ffind_operation_coding_system above is not enough=2E >It would have to be not using args2 after the GC has run=2E Maybe that's >_in_ Ffind_operation_coding_system=2E > >In the new GC, with MPS, the same is true as above=2E An object which is >only referenced from args2 may die=2E Right, because the backing storage for args2 might be in the mallloc heap,= and GC doesn't scan the mallloc heap=2E >Additionally, objects might not die but may move, assuming that >SAFE_NALLOCA does not create an ambiguous root=2E So, using SAFE_NALLOCA >makes another assumption in the MPS case: that something else prevents >the objects from moving=2E Another proof or check required with my GCPRO >hat on=2E Yes=2E In any system, a reference the GC doesn't know about must be assume= d to be garbage the instant it's created=2E Every object is dead unless the= GC can prove it's alive=2E >> 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=2E In call_process I see that we only ever put >> Lisp objects into the memory allocated by SAFE_NALLOCA=2E If that is >> unsafe, could you tell what MPS does during GC which makes this >> unsafe? > >Not sure, is the question why in MPS both pointers and Lisp_Object count >as "references"? > >If it's that, it's basically the same in the old GC=2E For example, when >marking the C stack, we must recognize both pointers to Lisp_Cons and >Lisp_Objects that look like conses, which contain such a pointer=2E=20 And a third case: interior pointers=2E A native pointer to a Lisp object i= sn't necessarily pointing to the start of that object=2E ------EN20G1X4PPGH1HCPMNGOMU7GD3X3W0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html><html><body><div dir=3D"auto">On January 5, 2025 9:11:08 AM = EST, "Gerd M=C3=B6llmann" <gerd=2Emoellmann@gmail=2Ecom> wrote:<br>&g= t;Eli Zaretskii <eliz@gnu=2Eorg> writes:<br>><br>>>> From= : Gerd M=C3=B6llmann <gerd=2Emoellmann@gmail=2Ecom><br>>>> C= c: pipcet@protonmail=2Ecom,=C2=A0 75322@debbugs=2Egnu=2Eorg<br>>>>= Date: Sat, 04 Jan 2025 11:20:41 +0100<br>>>> <br>>>> In = callproc=2Ec I found two: call_process and create_temp_file both use<br>>= ;>> SAFE_NALLOCA to store Lisp_Objects=2E I think these should be rep= laces<br>>>> with SAVE_ALLOCA_LISP=2E<br>>><br>>> What= are the conditions under which placing Lisp objects into<br>>> SAFE_= NALLOCA is not safe?<br>>><br>>> I understand that the first co= ndition is that SAFE_NALLOCA uses<br>>> xmalloc instead of alloca=2E<= br>><br>>Right=2E If it doesn't use xmalloc, the references are on th= e C stack, and<br>>both old and new GC handle that by scanning the C sta= ck=2E<br>><br>>> But what are the other conditions?=C2=A0 Is one o= f them that GC could<br>>> happen while these Lisp objects are in the= memory allocated by<br>>> SAFE_NALLOCA off the heap?=C2=A0 <br>><= br>>Yes=2E<br>><br>>> IOW, if no GC happen, is that still unsaf= e? And if GC _can_ happen,<br>>> but we don't use the allocated block= again, is that a problem? For<br>>> example, in this fragment:<br>&g= t;><br>>> =C2=A0=C2=A0=C2=A0 SAFE_NALLOCA (args2, 1, nargs + 1);<= br>>> =C2=A0=C2=A0=C2=A0 args2[0] =3D Qcall_process;<br>>> = =C2=A0=C2=A0=C2=A0 for (i =3D 0; i < nargs; i++) args2[i + 1] =3D args[i= ];<br>>> =C2=A0=C2=A0=C2=A0 coding_systems =3D Ffind_operation_codin= g_system (nargs + 1, args2);<br>>> =C2=A0=C2=A0=C2=A0 val =3D CONSP = (coding_systems) ? XCDR (coding_systems) : Qnil;<br>>><br>>> Le= t's say Ffind_operation_coding_system could trigger GC=2E=C2=A0 But we<br>&= gt;> never again use the args2[] array after Ffind_operation_coding_syst= em<br>>> returns=2E=C2=A0 Is the above still unsafe?=C2=A0 If so, cou= ld you tell what<br>>> could MPS do during GC to make this unsafe?<br= >><br>>Let me first say why I find this unsafe in the old GC, in prin= ciple=2E If<br>>we don't assume anything about the objects referenced fr= om args2, then a<br>>reference in args2 may well be the only one to some= object=2E In this<br>>case, the old GC would sweep it=2E<br><br>Gerd is= right=2E This pattern was never safe=2E<br><br>> Or, the other way 'rou= nd, by using<br>>SAFE_NALLOCA we make an assumption=2E And that, from my= (GCPRO) POV, needs<br>>a proof, or better yet some check in code=2E<br>= ><br>>Not using arg2 after Ffind_operation_coding_system above is not= enough=2E<br>>It would have to be not using args2 after the GC has run= =2E Maybe that's<br>>_in_ Ffind_operation_coding_system=2E<br>><br>&g= t;In the new GC, with MPS, the same is true as above=2E An object which is<= br>>only referenced from args2 may die=2E<br><br>Right, because the back= ing storage for args2 might be in the mallloc heap, and GC doesn't scan the= mallloc heap=2E<br><br>>Additionally, objects might not die but may mov= e, assuming that<br>>SAFE_NALLOCA does not create an ambiguous root=2E S= o, using SAFE_NALLOCA<br>>makes another assumption in the MPS case: that= something else prevents<br>>the objects from moving=2E Another proof or= check required with my GCPRO<br>>hat on=2E<br><br>Yes=2E In any system,= a reference the GC doesn't know about must be assumed to be garbage the in= stant it's created=2E Every object is dead unless the GC can prove it's ali= ve=2E<br><br>>> Also, in some other message you said SAFE_NALLOCA is = unsafe if<br>>> _pointers_ to Lisp objects are placed in the memory S= AFE_NALLOCA<br>>> allocates off the heap=2E=C2=A0 In call_process I s= ee that we only ever put<br>>> Lisp objects into the memory allocated= by SAFE_NALLOCA=2E=C2=A0 If that is<br>>> unsafe, could you tell wha= t MPS does during GC which makes this<br>>> unsafe?<br>><br>>No= t sure, is the question why in MPS both pointers and Lisp_Object count<br>&= gt;as "references"?<br>><br>>If it's that, it's basically the same in= the old GC=2E For example, when<br>>marking the C stack, we must recogn= ize both pointers to Lisp_Cons and<br>>Lisp_Objects that look like conse= s, which contain such a pointer=2E <br><br>And a third case: interior point= ers=2E A native pointer to a Lisp object isn't necessarily pointing to the = start of that object=2E</div></body></html> ------EN20G1X4PPGH1HCPMNGOMU7GD3X3W0--
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 5 Jan 2025 21:01:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 16:01:25 2025 Received: from localhost ([127.0.0.1]:35477 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUXkS-0001qL-TB for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 16:01:25 -0500 Received: from lists.gnu.org ([2001:470:142::17]:49326) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1tUXkL-0001pg-5E for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 16:01:20 -0500 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 <dancol@HIDDEN>) id 1tUXkE-00084v-Rh for bug-gnu-emacs@HIDDEN; Sun, 05 Jan 2025 16:01:10 -0500 Received: from dancol.org ([2600:3c01:e000:3d8::1]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <dancol@HIDDEN>) id 1tUXk9-0002Pl-VY; Sun, 05 Jan 2025 16:01:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=dancol.org; s=x; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID: References:In-Reply-To:Subject:CC:To:From:Date:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=m5NHn3Q8s2jgMoBinmO9HnIBkb4UM3ZHvpuYkKiAxvU=; b=oXPoWoyRUGv/E8YJ9QMSqCac99 oraDlWkgHbmOMT6SKAoazsqjXns9Lyi9bRMyqGsK2Vt9sUMUyO424t/gfMEZtQVLE5YFZ8CdSM9DL iBTsxHGG6yZ/6KtS18uk7E/hz3VJuKqg7N32zbjg0mcnxxUrmWRyeQY7TofXh4VzSNstTH9cdKPz7 +RUIbgrALQQhY+CgBx8FiFuzqwa8CVujdBOgH1ZC3SbSx2MrLnxxmyE48Dq5SlnllTLfXrrd1E6rZ THjeTWDYp4jFO6Fkb1nY4Ms+QVs4OvLs+V7/S9TqE9RgGRcBAq3f6J3tzO3FKwR05JUzxMfw2vpri 81m6CDVQ==; Received: from 2603-9001-4203-1ab2-9d33-bea9-4999-a2af.inf6.spectrum.com ([2603:9001:4203:1ab2:9d33:bea9:4999:a2af]:60724 helo=[IPv6:::1]) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1tUXk3-00064v-2f; Sun, 05 Jan 2025 16:01:00 -0500 Date: Sun, 05 Jan 2025 16:01:00 -0500 From: Daniel Colascione <dancol@HIDDEN> To: bug-gnu-emacs@HIDDEN, =?ISO-8859-1?Q?Gerd_M=F6llmann?= <gerd.moellmann@HIDDEN>, Eli Zaretskii <eliz@HIDDEN> Subject: =?US-ASCII?Q?Re=3A_bug=2375322=3A_SAFE=5FALLOCA_assumed_?= =?US-ASCII?Q?to_root_Lisp=5FObjects/SSDATA=28string=29?= User-Agent: K-9 Mail for Android In-Reply-To: <m2v7uttkoz.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> Message-ID: <225431A0-98C1-4F95-B290-AB86F5379030@HIDDEN> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=----EN20G1X4PPGH1HCPMNGOMU7GD3X3W0 Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2600:3c01:e000:3d8::1; envelope-from=dancol@HIDDEN; helo=dancol.org 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, HTML_MESSAGE=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: 0.9 (/) X-Debbugs-Envelope-To: submit Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.1 (/) ------EN20G1X4PPGH1HCPMNGOMU7GD3X3W0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On January 5, 2025 9:11:08 AM EST, "Gerd M=C3=B6llmann" <gerd=2Emoellmann@g= mail=2Ecom> wrote: >Eli Zaretskii <eliz@gnu=2Eorg> writes: > >>> From: Gerd M=C3=B6llmann <gerd=2Emoellmann@gmail=2Ecom> >>> Cc: pipcet@protonmail=2Ecom, 75322@debbugs=2Egnu=2Eorg >>> Date: Sat, 04 Jan 2025 11:20:41 +0100 >>>=20 >>> In callproc=2Ec I found two: call_process and create_temp_file both us= e >>> SAFE_NALLOCA to store Lisp_Objects=2E I think these should be replaces >>> with SAVE_ALLOCA_LISP=2E >> >> 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=2E > >Right=2E If it doesn't use xmalloc, the references are on the C stack, an= d >both old and new GC handle that by scanning the C stack=2E > >> 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? =20 > >Yes=2E > >> 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] =3D Qcall_process; >> for (i =3D 0; i < nargs; i++) args2[i + 1] =3D args[i]; >> coding_systems =3D Ffind_operation_coding_system (nargs + 1, args2= ); >> val =3D CONSP (coding_systems) ? XCDR (coding_systems) : Qnil; >> >> Let's say Ffind_operation_coding_system could trigger GC=2E But we >> never again use the args2[] array after Ffind_operation_coding_system >> returns=2E Is the above still unsafe? If so, could you tell what >> could MPS do during GC to make this unsafe? > >Let me first say why I find this unsafe in the old GC, in principle=2E If >we don't assume anything about the objects referenced from args2, then a >reference in args2 may well be the only one to some object=2E In this >case, the old GC would sweep it=2E Gerd is right=2E This pattern was never safe=2E > Or, the other way 'round, by using >SAFE_NALLOCA we make an assumption=2E And that, from my (GCPRO) POV, need= s >a proof, or better yet some check in code=2E > >Not using arg2 after Ffind_operation_coding_system above is not enough=2E >It would have to be not using args2 after the GC has run=2E Maybe that's >_in_ Ffind_operation_coding_system=2E > >In the new GC, with MPS, the same is true as above=2E An object which is >only referenced from args2 may die=2E Right, because the backing storage for args2 might be in the mallloc heap,= and GC doesn't scan the mallloc heap=2E >Additionally, objects might not die but may move, assuming that >SAFE_NALLOCA does not create an ambiguous root=2E So, using SAFE_NALLOCA >makes another assumption in the MPS case: that something else prevents >the objects from moving=2E Another proof or check required with my GCPRO >hat on=2E Yes=2E In any system, a reference the GC doesn't know about must be assume= d to be garbage the instant it's created=2E Every object is dead unless the= GC can prove it's alive=2E >> 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=2E In call_process I see that we only ever put >> Lisp objects into the memory allocated by SAFE_NALLOCA=2E If that is >> unsafe, could you tell what MPS does during GC which makes this >> unsafe? > >Not sure, is the question why in MPS both pointers and Lisp_Object count >as "references"? > >If it's that, it's basically the same in the old GC=2E For example, when >marking the C stack, we must recognize both pointers to Lisp_Cons and >Lisp_Objects that look like conses, which contain such a pointer=2E=20 And a third case: interior pointers=2E A native pointer to a Lisp object i= sn't necessarily pointing to the start of that object=2E ------EN20G1X4PPGH1HCPMNGOMU7GD3X3W0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html><html><body><div dir=3D"auto">On January 5, 2025 9:11:08 AM = EST, "Gerd M=C3=B6llmann" <gerd=2Emoellmann@gmail=2Ecom> wrote:<br>&g= t;Eli Zaretskii <eliz@gnu=2Eorg> writes:<br>><br>>>> From= : Gerd M=C3=B6llmann <gerd=2Emoellmann@gmail=2Ecom><br>>>> C= c: pipcet@protonmail=2Ecom,=C2=A0 75322@debbugs=2Egnu=2Eorg<br>>>>= Date: Sat, 04 Jan 2025 11:20:41 +0100<br>>>> <br>>>> In = callproc=2Ec I found two: call_process and create_temp_file both use<br>>= ;>> SAFE_NALLOCA to store Lisp_Objects=2E I think these should be rep= laces<br>>>> with SAVE_ALLOCA_LISP=2E<br>>><br>>> What= are the conditions under which placing Lisp objects into<br>>> SAFE_= NALLOCA is not safe?<br>>><br>>> I understand that the first co= ndition is that SAFE_NALLOCA uses<br>>> xmalloc instead of alloca=2E<= br>><br>>Right=2E If it doesn't use xmalloc, the references are on th= e C stack, and<br>>both old and new GC handle that by scanning the C sta= ck=2E<br>><br>>> But what are the other conditions?=C2=A0 Is one o= f them that GC could<br>>> happen while these Lisp objects are in the= memory allocated by<br>>> SAFE_NALLOCA off the heap?=C2=A0 <br>><= br>>Yes=2E<br>><br>>> IOW, if no GC happen, is that still unsaf= e? And if GC _can_ happen,<br>>> but we don't use the allocated block= again, is that a problem? For<br>>> example, in this fragment:<br>&g= t;><br>>> =C2=A0=C2=A0=C2=A0 SAFE_NALLOCA (args2, 1, nargs + 1);<= br>>> =C2=A0=C2=A0=C2=A0 args2[0] =3D Qcall_process;<br>>> = =C2=A0=C2=A0=C2=A0 for (i =3D 0; i < nargs; i++) args2[i + 1] =3D args[i= ];<br>>> =C2=A0=C2=A0=C2=A0 coding_systems =3D Ffind_operation_codin= g_system (nargs + 1, args2);<br>>> =C2=A0=C2=A0=C2=A0 val =3D CONSP = (coding_systems) ? XCDR (coding_systems) : Qnil;<br>>><br>>> Le= t's say Ffind_operation_coding_system could trigger GC=2E=C2=A0 But we<br>&= gt;> never again use the args2[] array after Ffind_operation_coding_syst= em<br>>> returns=2E=C2=A0 Is the above still unsafe?=C2=A0 If so, cou= ld you tell what<br>>> could MPS do during GC to make this unsafe?<br= >><br>>Let me first say why I find this unsafe in the old GC, in prin= ciple=2E If<br>>we don't assume anything about the objects referenced fr= om args2, then a<br>>reference in args2 may well be the only one to some= object=2E In this<br>>case, the old GC would sweep it=2E<br><br>Gerd is= right=2E This pattern was never safe=2E<br><br>> Or, the other way 'rou= nd, by using<br>>SAFE_NALLOCA we make an assumption=2E And that, from my= (GCPRO) POV, needs<br>>a proof, or better yet some check in code=2E<br>= ><br>>Not using arg2 after Ffind_operation_coding_system above is not= enough=2E<br>>It would have to be not using args2 after the GC has run= =2E Maybe that's<br>>_in_ Ffind_operation_coding_system=2E<br>><br>&g= t;In the new GC, with MPS, the same is true as above=2E An object which is<= br>>only referenced from args2 may die=2E<br><br>Right, because the back= ing storage for args2 might be in the mallloc heap, and GC doesn't scan the= mallloc heap=2E<br><br>>Additionally, objects might not die but may mov= e, assuming that<br>>SAFE_NALLOCA does not create an ambiguous root=2E S= o, using SAFE_NALLOCA<br>>makes another assumption in the MPS case: that= something else prevents<br>>the objects from moving=2E Another proof or= check required with my GCPRO<br>>hat on=2E<br><br>Yes=2E In any system,= a reference the GC doesn't know about must be assumed to be garbage the in= stant it's created=2E Every object is dead unless the GC can prove it's ali= ve=2E<br><br>>> Also, in some other message you said SAFE_NALLOCA is = unsafe if<br>>> _pointers_ to Lisp objects are placed in the memory S= AFE_NALLOCA<br>>> allocates off the heap=2E=C2=A0 In call_process I s= ee that we only ever put<br>>> Lisp objects into the memory allocated= by SAFE_NALLOCA=2E=C2=A0 If that is<br>>> unsafe, could you tell wha= t MPS does during GC which makes this<br>>> unsafe?<br>><br>>No= t sure, is the question why in MPS both pointers and Lisp_Object count<br>&= gt;as "references"?<br>><br>>If it's that, it's basically the same in= the old GC=2E For example, when<br>>marking the C stack, we must recogn= ize both pointers to Lisp_Cons and<br>>Lisp_Objects that look like conse= s, which contain such a pointer=2E <br><br>And a third case: interior point= ers=2E A native pointer to a Lisp object isn't necessarily pointing to the = start of that object=2E</div></body></html> ------EN20G1X4PPGH1HCPMNGOMU7GD3X3W0--
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 20:24:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 15:24:36 2025 Received: from localhost ([127.0.0.1]:35399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUXAp-0007t8-LB for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 15:24:36 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52346) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUXAn-0007sk-U6 for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 15:24:34 -0500 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 <eliz@HIDDEN>) id 1tUXAi-00029c-Fh; Sun, 05 Jan 2025 15:24:28 -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=WpNpTfV7zE8rScwnNporfzp8q6pKXUlzXFQaIaAhJ7Y=; b=SNlPxPeCAeFoWjVrL1jJ nP3dEMBWCmtdx+xsafdtWeYJk7RFg5P/IrGbmkZqwxnjk5vV8BHTCoTCb/TX0ULdxBtSAXA9U4Rbz DEgmTXgO1w52Y3CdxybswZxIkG/9Mh+cxq8wzvkyQBfi6B2CBdlB5vgRTlZDhhE9f6uvzfmfqdxR6 9KAc4ISCBuIhcfoYezMkE2GSOrCRoykc6zsIuvol+xcQllB4ljIsL6u4Yj+xqeVG4dZo7Ss4aC6AL KSYaq3tHB1QAMc5U09LzP54DV7oM5QOXENG+pv2i51MlOSLhQDo5wugFRnc+hbWoWEK8QE7A2pXW3 FJ0P7juNt6vONg==; Date: Sun, 05 Jan 2025 22:24:23 +0200 Message-Id: <868qrp6mbs.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2wmf9rpqv.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sun, 05 Jan 2025 21:04:56 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> <86msg56to8.fsf@HIDDEN> <m25xmtt9a6.fsf@HIDDEN> <86h66d6pw1.fsf@HIDDEN> <m2wmf9rpqv.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org > Date: Sun, 05 Jan 2025 21:04:56 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > How can we possibly make sure this works reliably and safely?? For > > each variable we have in every function, we will need to analyze > > whether the variable is > > > > . an automatic variable > > . a static variable that is protected by someone > > . a global variable that is protected by someone > > . a result of dereferencing a pointer that is somehow protected > > > > etc. etc., where "protected by someone" means that it is a descendant > > of some staticpro, or of some root, or... > > > > And if we cannot prove to ourselves that one of the above happens, > > then we'd need to force a copy of the variable to be on the stack? > > > > Does this sound practical? > > > > If this is the price of using MPS, and I'm not missing something > > obvious, then it sounds like we should run away from MPS, fast. > > Because we will sooner or later have to rewrite every single line of > > code we ever wrote. > > I'm bowing out again. It's not worth it. I don't understand why? I need to understand the implications to be able to make decisions, which are part of my job. So I ask questions, and I'm grateful for your answers, which clarify the issues for me. That I sometimes sound overwhelmed by the implications shouldn't be held against me, it's just a normal human reaction, nothing more. If I somehow sound impolite, I apologize.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 20:05:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 15:05:08 2025 Received: from localhost ([127.0.0.1]:35365 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUWs0-0006wY-9Y for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 15:05:08 -0500 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:59523) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUWrx-0006sh-Le for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 15:05:06 -0500 Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-3862df95f92so5979622f8f.2 for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 12:05:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736107499; x=1736712299; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=F+pZ3BGIF5n/uoMpYqXc46Z41ISv1vbtZXFO/MXbhWs=; b=DqeFH/0arfE0hXC5ARFIfD4HJVsbR2obog8aVeP2TGa+hNAFfMnyRtgJ8N/7/JZHwk VvIHSSVWXqJZ5kkHh0AtWpURtJhMl95CcMbReR5jTggjJqfmP/GbaUKW9zuXMDvr55te zwxXYPtlOXrx1PupJcAbB8+9vhBnZOl/HhHpFilGyBAGd8Eo6i5Awx3feuOjVgL7W/6M JWzTCcY3WGVy/YRuCHlKEQeiiw21qrv1++GJnPyugDxJxUp0XAICmNDCAY5Pu78DAazn MeIn71V2FuHTvetNf8pEZ7WZPiZHllY1762EQeM0GRJphaHFG+JOQegKLw0d5S4im9fl nKxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736107499; x=1736712299; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=F+pZ3BGIF5n/uoMpYqXc46Z41ISv1vbtZXFO/MXbhWs=; b=L3tLNhVSgRqYDoV2AOecUsEZQWdF8NPTX4lurqFIq900jksq/o/RJmg2Nidek7+Kej BbGFfnSYsj0ZhbjUF8ad+mIPHRViS+nTQtA21y/Ab8uZ+Ykp7YVvKc/OoFh5/YwltdoT ZhtIru+tkZnR+bvjuI9xnZCjhRS40dituNXJ9RjrDm6NxicgzWwk+w7xIu2FYsFVC7ul d3yAugLn/TzPA1xEnj1PqmvhjO+ZwEJoUU6JVJu/2ddReAbFRkJuW12c7wioSd598zRb nwMCB5vaVOps86/6evgAfj/yYDwj7xjkXIY4qZmjaUhOzaFkWhmDnYxkIWItuaTrsZuO W4Zg== X-Forwarded-Encrypted: i=1; AJvYcCW94ASaI5Ew/Z1hGjjWS/x+opYKQpOGNwVvoaRWUODexRNI/0vXTjDIBKUy0djVg/2HFkVx7g==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yxpmf/QNl4cmRCGoMjac9dsYlIa0+9YMChyR6/AlM/67N//Vh2F 5T+AK4YYA0971Kavbv2Fl+KUOdz8WD6pTFbLlAcXr8gs9aON1YiN+tjmzw== X-Gm-Gg: ASbGncuYfARjAm2vufTt/pJQva0crp7GHCaoYQ3J8Hr+NY1AMSXwL45K5LlsAYy0z4M HM4Dfg93pNYOSGnOBrQpiRIgR0lbTRg6N/mw8n/0sz00FMLdX0lO4e49w/xWYtxbkPw+0HjN9qK oL6tfVAyCovLTEMQFGHsmwwvVxrIPhnhvTniII0kdxffh5Bx1+aJUjoNyVgIieYbY1KusUhOS/Z JlprpULfwIosdnleXpM1bZinqGzWaEX1ITayDuxPxzDwLy1L/02xBBGv7rQRfhH/EBn0EL1iGuS R1kuXeo7yX+O1+jXWJP6+99wJNIxAH9Y31Jdr3tXSd1JMV4hpdujiLlHJITcC+lQYg== X-Google-Smtp-Source: AGHT+IEUzTdMUcRwj8TGaaWicE8fObC5/1H/eD/Jbu3Q3HSPV3c3G0eqoH0t7hPss5/PrUuSXNMDWQ== X-Received: by 2002:a5d:598d:0:b0:385:e013:39ef with SMTP id ffacd0b85a97d-38a221e30aemr41580260f8f.6.1736107498767; Sun, 05 Jan 2025 12:04:58 -0800 (PST) Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c832ec4sm45609955f8f.26.2025.01.05.12.04.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 12:04:58 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <86h66d6pw1.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 05 Jan 2025 21:07:26 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> <86msg56to8.fsf@HIDDEN> <m25xmtt9a6.fsf@HIDDEN> <86h66d6pw1.fsf@HIDDEN> Date: Sun, 05 Jan 2025 21:04:56 +0100 Message-ID: <m2wmf9rpqv.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org >> Date: Sun, 05 Jan 2025 19:17:37 +0100 >>=20 >> Eli Zaretskii <eliz@HIDDEN> writes: >>=20 >> > OK, but in most, if not all of these cases, the objects are referenced >> > from the stack. For example, in the above fragment, the args[] array >> > is on the stack. Right? >>=20 >> That args is a parameter >>=20 >> call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd, >>=20 >> So just from this I see only args itself on the stack, not args[0], >> args[1] and so on. I would have to look at all callers to determine >> that. Not good enough in my book. > > So what, we will now need to copy every args[] into a Lisp vector > created by SAFE_ALLOCA_LISP, or xstrdup all of them, and do it in > each and every function that gets the args[] array, all the way down > to where the array is finally used (because usually we have 3 or 4 > nested levels that pass args[] to one another)? That's insane! > >> > What does it mean in detail "the object may move"? A Lisp object is a >> > tagged pointer. Do you mean the pointer should no point to a >> > different address, i.e. the value of a Lisp object as a number should >> > change to still be valid?=20=20 >>=20 >> Exactly. Unless an ambiguous reference prevents the copying that can >> happen. > > How can we possibly make sure this works reliably and safely?? For > each variable we have in every function, we will need to analyze > whether the variable is > > . an automatic variable > . a static variable that is protected by someone > . a global variable that is protected by someone > . a result of dereferencing a pointer that is somehow protected > > etc. etc., where "protected by someone" means that it is a descendant > of some staticpro, or of some root, or... > > And if we cannot prove to ourselves that one of the above happens, > then we'd need to force a copy of the variable to be on the stack? > > Does this sound practical? > > If this is the price of using MPS, and I'm not missing something > obvious, then it sounds like we should run away from MPS, fast. > Because we will sooner or later have to rewrite every single line of > code we ever wrote. I'm bowing out again. It's not worth it.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 19:07:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 14:07:37 2025 Received: from localhost ([127.0.0.1]:35250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUVyK-0003nf-Ub for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 14:07:37 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51102) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUVyJ-0003nS-P8 for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 14:07:36 -0500 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 <eliz@HIDDEN>) id 1tUVyD-0006of-Fv; Sun, 05 Jan 2025 14:07:29 -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=DTqbswfqr93AvLdai1CutRWu5QJ1AnORac4HqnCHdD8=; b=diPn6qIBy3val9fkjbOp oj0siuL1DsIV0de6iI57SSIDwAOO0OppMbKc2Bg/GlQdDIGZwxwB6ESfQdule/P1A26GpFNq7i8ax XvgdpbrAHHaaNhldXDjNjVwudBRGLFRSNaYPtU+8J6setbgUEqRyEr0WKMsCyKk2gWBL0vQK/3ffM 72FfpD2aYba4cJE/ltZOnzuKsMPY+j5vf/lq6Zq2iEgKGFi6N58xPYIT633B/K3Fxf2miqCm/FgKt 0wwuzeqYwoD7+U3QsW9lmPVz9u3xLSttMAM4ffCilHlEk3Zl++hD5YZfmXrrSARRoGB630pqHI2hn RMHbcSqiCb+0IQ==; Date: Sun, 05 Jan 2025 21:07:26 +0200 Message-Id: <86h66d6pw1.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m25xmtt9a6.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sun, 05 Jan 2025 19:17:37 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> <86msg56to8.fsf@HIDDEN> <m25xmtt9a6.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org > Date: Sun, 05 Jan 2025 19:17:37 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > OK, but in most, if not all of these cases, the objects are referenced > > from the stack. For example, in the above fragment, the args[] array > > is on the stack. Right? > > That args is a parameter > > call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd, > > So just from this I see only args itself on the stack, not args[0], > args[1] and so on. I would have to look at all callers to determine > that. Not good enough in my book. So what, we will now need to copy every args[] into a Lisp vector created by SAFE_ALLOCA_LISP, or xstrdup all of them, and do it in each and every function that gets the args[] array, all the way down to where the array is finally used (because usually we have 3 or 4 nested levels that pass args[] to one another)? That's insane! > > What does it mean in detail "the object may move"? A Lisp object is a > > tagged pointer. Do you mean the pointer should no point to a > > different address, i.e. the value of a Lisp object as a number should > > change to still be valid? > > Exactly. Unless an ambiguous reference prevents the copying that can > happen. How can we possibly make sure this works reliably and safely?? For each variable we have in every function, we will need to analyze whether the variable is . an automatic variable . a static variable that is protected by someone . a global variable that is protected by someone . a result of dereferencing a pointer that is somehow protected etc. etc., where "protected by someone" means that it is a descendant of some staticpro, or of some root, or... And if we cannot prove to ourselves that one of the above happens, then we'd need to force a copy of the variable to be on the stack? Does this sound practical? If this is the price of using MPS, and I'm not missing something obvious, then it sounds like we should run away from MPS, fast. Because we will sooner or later have to rewrite every single line of code we ever wrote.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 19:02:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 14:02:28 2025 Received: from localhost ([127.0.0.1]:35242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUVtM-0003Y2-3Y for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 14:02:28 -0500 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:58723) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUVtJ-0003Xs-Ir for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 14:02:26 -0500 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-4362bae4d7dso98090595e9.1 for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 11:02:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736103744; x=1736708544; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=8/2wdGAu3AWNdB6Aj6MZxTzAUYdtcwCydhAYkHc8OIs=; b=mDwbdRhHSDy/J+0ALPWeMNs/mt4PODnoMCylxHP+3fPPyKrTHHGzqn4l5STIr1FPB1 fR0N5+7IyYvb6edp1/GU/vHFQlBzSpgt672GzsNLay3jd0KccgCxx1t1w+z+aERqr6WR 0Xv1bIE8QnN8/nrXrLCHbApqijR3OIVF1BjANm0wZEbMOoHL8CQadlZAct6pSytDsNau 0YRjuwmQwa/11anCOlttN/pvPqZaPXp4BPNxzSxf4Y371gLj+ko4gUQuh4YOoPraA/Yo DeGNqyf8OYq4u7/95nd9Dc/Qeo6fDe7UdLM26zSm2lG60eA4QAZrg0cSJhjKDaPeHs4Y Ag8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736103744; x=1736708544; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=8/2wdGAu3AWNdB6Aj6MZxTzAUYdtcwCydhAYkHc8OIs=; b=eNVhhqEfDPZ35cr34zZHAU1kLLie39j9mMeR3ijbxTQeOjBUSGYuQ9UAjUvqfAoGNn vXpdmW9D1mRbeH1CONl3+f30lQ4ZzTnyMvxPgINvWi9E+ALAEV9U0KNSGRTDWY6CK9Fc negmEn6SKLgdLbOvn8wqVgNkEe8HHas1VTtLqG5qneLX8Z144Fzo1iltyh+vWTP6ktUJ qKvEzkRK77NAM3d7VKGO9za+e64DZMz5i1J/TxK/0ZFQwgJIz3O/lN8pmJzWZFvY6NrG Ya0f6WeDQOjH9+sx0jgvmnFbvFf2c6UttQqsoToyVJ0hDtGYnvaUE34oDu7fs2w6OQwJ UCBg== X-Forwarded-Encrypted: i=1; AJvYcCUVA1ONh8VdZOzvU0Vdoras3Q/LeYjvA9+Ab5F0OmuHPzqy1M3Kmvg0EgvF/uQUiZG8Y294aA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YysoFWkYRXir8hYJdYEAzgNlgsGAhaGZTwSwsVCZQ8rUkAJ0hhX K24qvu3IewevXvNzBK8ZPWUBh9HdIgRntx8jXbC9XG8ODFjjw7KArxKxmQ== X-Gm-Gg: ASbGncu70cqnydgGNtt6SCs1Mu7qf4vY+7FjPjpTkvLgT4ernNVnfJ6ZbBax9jr9gpT zZopb72zagriiSl+WHwcRkanAZEcrz7QREYDlg9FsF1TRhBa11rlk3HQ4mWDA/NfDh18VcoHXP1 e/UBqZK8pdwQ5xNZqXY5+2gqHNqXNEQ/5PZ3mmhVAXPyDEadXwkDiFLIBkwuF8cLXClUMA9XT2d pld2VOJCZUGdYabkcxhI23MM0/pnT/dHQNP7j7Kku4AzDNYLnXl/+eYxVGF6fS8DxngqiDdtTww T46b/35a6rHaeX5W3WbtiDvnFO2OoJehOS3HkLuk5dNx+kCfZIxfYcARex7Y9Obcfg== X-Google-Smtp-Source: AGHT+IFB4uhSH8T6eK6Q0aNDMhaZkMKizxIc7iT8JXaQBLbjiX9gPVAdXsF0/W4HWn0gPF1NwQSC7A== X-Received: by 2002:a5d:5f4a:0:b0:385:fdc2:1808 with SMTP id ffacd0b85a97d-38a223f7172mr51071288f8f.40.1736103743332; Sun, 05 Jan 2025 11:02:23 -0800 (PST) Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c8475cesm45811436f8f.57.2025.01.05.11.02.22 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 11:02:22 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <86ldvp6r1e.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 05 Jan 2025 20:42:37 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <m25xmtwxt7.fsf@HIDDEN> <86sepx8sth.fsf@HIDDEN> <m2wmf9v9ho.fsf@HIDDEN> <86h66d8pnl.fsf@HIDDEN> <m2frlxv6d5.fsf@HIDDEN> <86ed1h8nji.fsf@HIDDEN> <m2zfk5tn0f.fsf@HIDDEN> <86o70l6ucl.fsf@HIDDEN> <m2a5c5takb.fsf@HIDDEN> <86ldvp6r1e.fsf@HIDDEN> Date: Sun, 05 Jan 2025 20:02:22 +0100 Message-ID: <m21pxht77l.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org >> Date: Sun, 05 Jan 2025 18:49:56 +0100 >>=20 >> Eli Zaretskii <eliz@HIDDEN> writes: >>=20 >> > This surprises me because on the master branch SAFE_ALLOCA_LISP either >> > calls alloca or xzalloc. So I don't see why SAFE_ALLOCA_LISP would be >> > safer in the old GC than SAFE_NALLOCA. It's only on the igc branch >> > that you made SAFE_ALLOCA_LISP make a Lisp vector. >> > But this is a tangent from my POV. I would like to discuss the new >> > GC, not the old one. >> > >>=20 >> This in SAFE_ALLOCA_LISP_EXTRA >>=20 >> (buf) =3D xzalloc (alloca_nbytes); \ >> record_unwind_protect_array (buf, nelt); \ >>=20 >> makes a specpdl entry, which makes mark_specpdl do this: >>=20 >> case SPECPDL_UNWIND_ARRAY: >> mark_objects (pdl->unwind_array.array, pdl->unwind_array.nelts); >> break; > > Thanks. I guess it's supposed to be "common knowledge" that > record_unwind_protect_* indirectly causes the objects to be marked... > > But then why don't we set the .mark member in SAFE_NALLOCA or some > variant thereof? Questions upon questions. I have no idea. It seems to be relatively new, i.e. younger than 20 years :-).
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 18:42:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 13:42:55 2025 Received: from localhost ([127.0.0.1]:35192 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUVaQ-0002SG-UL for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 13:42:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48224) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUVaN-0002S2-Kh for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 13:42:53 -0500 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 <eliz@HIDDEN>) id 1tUVaH-0001aY-UG; Sun, 05 Jan 2025 13:42:45 -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=ksdRAmOixCU8bRtI80IfzOlpum8pFi0ENWfyCNjADWY=; b=mAx2+4ycyKW8YSXKgKVQ /+mx9XHgY4Lhx1Ky3sRa4o+//OkZA1oZTy3O3VoYR7lJ9OU9GhlAXi9wWkH7APIi44gTivrw3LZ05 46/LPwBHr8aLFCzLf8XokEYkmQ8vg9cz8wTWC1rAKoYbBlC/QO31dPTs8OaaFSGMrVb/hSqkoTsx6 jeAmKS6CvN2e9Qi34NxjorCGdny4lEz0k6q9uOyGZIN3yoDzzQNPXLeKgFJRo9gGCCdyMja6toztm WshRGwBk9GTmVc2ZphXREUzIY7ulkvohS3b+LJb2WwdaHf24sKD5uATtR+ZjrIL5e2nSKniF7XBWu Ph4LWVMuZccPNQ==; Date: Sun, 05 Jan 2025 20:42:37 +0200 Message-Id: <86ldvp6r1e.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2a5c5takb.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sun, 05 Jan 2025 18:49:56 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <m25xmtwxt7.fsf@HIDDEN> <86sepx8sth.fsf@HIDDEN> <m2wmf9v9ho.fsf@HIDDEN> <86h66d8pnl.fsf@HIDDEN> <m2frlxv6d5.fsf@HIDDEN> <86ed1h8nji.fsf@HIDDEN> <m2zfk5tn0f.fsf@HIDDEN> <86o70l6ucl.fsf@HIDDEN> <m2a5c5takb.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org > Date: Sun, 05 Jan 2025 18:49:56 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > This surprises me because on the master branch SAFE_ALLOCA_LISP either > > calls alloca or xzalloc. So I don't see why SAFE_ALLOCA_LISP would be > > safer in the old GC than SAFE_NALLOCA. It's only on the igc branch > > that you made SAFE_ALLOCA_LISP make a Lisp vector. > > But this is a tangent from my POV. I would like to discuss the new > > GC, not the old one. > > > > This in SAFE_ALLOCA_LISP_EXTRA > > (buf) = xzalloc (alloca_nbytes); \ > record_unwind_protect_array (buf, nelt); \ > > makes a specpdl entry, which makes mark_specpdl do this: > > case SPECPDL_UNWIND_ARRAY: > mark_objects (pdl->unwind_array.array, pdl->unwind_array.nelts); > break; Thanks. I guess it's supposed to be "common knowledge" that record_unwind_protect_* indirectly causes the objects to be marked... But then why don't we set the .mark member in SAFE_NALLOCA or some variant thereof?
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 18:17:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 13:17:45 2025 Received: from localhost ([127.0.0.1]:35134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUVC5-000179-1l for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 13:17:45 -0500 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:43487) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUVC1-00016v-QZ for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 13:17:43 -0500 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-43626213fffso85321285e9.1 for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 10:17:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736101059; x=1736705859; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=sKwICosqQGUWMOSULo+wXkpI9RhyQUSNyvGxhC6LwMw=; b=mOj5g1BnZOef1KugVd4hdN5GBM6OKF99i272wRQ+sO45bkPduWO1nEf9IxHZVu0O0V 6meF6rPvGTOa+rs0xpHtznMusawWqdyzasOw1ejWPMzAr+gBVR/LHDBKJo4qn6sOqks2 h0pRbqVpeuuHdk4dy3XAbsFp3a4JDNYZsJj4tTygSuxtgg1gdj5qh+NfQ3SOPf0qK1DF rcS6bdLd81pqHOBLSYYr+dgSANyjbm+r7oUh56p/bBcnp9RREwtMxa+beujjL9iU4Z4r Wt3y0yzyVGa8VpSjC8N0b9m6Ve5R+FViupLJmklWnmA4LtlGLMetrDrYqlnIovziaJey M4kw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736101059; x=1736705859; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=sKwICosqQGUWMOSULo+wXkpI9RhyQUSNyvGxhC6LwMw=; b=AzaWYr0Hxyhi2c/N5arxYa0BKJtAGanegF5QU1QNywYWDBpQXzngm9NLifmT97bMHC BQjxxwDMlT1Z4Qhv8dmoQK75VsdkTrcJaMFd7PXJVKMYLv9dAVeh939KZrFjkRXhHb44 1RiI0SDEvaKbskeHnZHy6Jna2GB9hakpHBed5UqZ00ji3jZoNZ3kSAysoonKWoa86JAS ICv03hTfAA8JCvXciQByWFNZQSB95frfokRFZOCOK34igk4wfYbKsme+tEsJyKPoz5HQ n8YCbnfPI/Hp3hTlWv3f/NAtiGwUWHSNPtldhGpe2tBLoK6kP6sRolEJQTGCPp/XMI9j LwQw== X-Forwarded-Encrypted: i=1; AJvYcCUCIS3sq0XDs+ygLGGqbCUeB+0e9NpowoW+0wHg2OUshWOtjcJWd7HjfOx31sy5VJ6QNuwfBQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxBS3wyaQ6jqtPbBJU/iz/emQLLuNYcWyZGjzqvF1glupILD5Jl tOpUmE+qnl0OusJIg6gds3SIF/UTcgZZbJ5aeqWSz7BNDEqI5LvGYk3uUw== X-Gm-Gg: ASbGnctXmollH1NZ2ISzi9BI/JKlRjCkpa6KgSEF+yoVvcPduKDVL8WZNRc6dMW/ED8 T9WPwNOtYh/yvL+WWEvGjbS6KK7oWJGyzJahdHo/cFIJ9l1B6LNSoZ9X/FeCHDhAeP6AXx872U1 Z7Lk+Dk8zCWBI+/8jwRYxiGkbyG6OGZnShnHxFyD+DFvA4yg8Uh8qEan/vY+Nd923lxpFdcGX7/ 5y4Xul/+DIMCj1IWQkqUrmSPF59UBXtd73YtXDrAQpXdmK2Lu0bQzxvPXmTpBPfRdCZ5DGP8eRs p7rT1jjYCK49GWHgvXmRscNJptx7Ph6D1ptAX+8BbrH8PkjfuNMwHtAkDY4hLS2D+g== X-Google-Smtp-Source: AGHT+IFiqMVLi/vAwBmzMRHwktImKEUuiLWluZMKFRe0go5+dZUwIcGf1Wuea0IjbzPFkgctMDzs7w== X-Received: by 2002:a05:600c:a0a:b0:434:9e17:190c with SMTP id 5b1f17b1804b1-436693f7cc4mr438177825e9.0.1736101059405; Sun, 05 Jan 2025 10:17:39 -0800 (PST) Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43661200abesm542439945e9.18.2025.01.05.10.17.37 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 10:17:39 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <86msg56to8.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 05 Jan 2025 19:45:43 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> <86msg56to8.fsf@HIDDEN> Date: Sun, 05 Jan 2025 19:17:37 +0100 Message-ID: <m25xmtt9a6.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org >> Date: Sun, 05 Jan 2025 15:11:08 +0100 >>=20 >> Eli Zaretskii <eliz@HIDDEN> writes: >>=20 >> > 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] =3D Qcall_process; >> > for (i =3D 0; i < nargs; i++) args2[i + 1] =3D args[i]; >> > coding_systems =3D Ffind_operation_coding_system (nargs + 1, args= 2); >> > val =3D 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? >>=20 >> Let me first say why I find this unsafe in the old GC, in principle. If >> we don't assume anything about the objects referenced from args2, then a >> reference in args2 may well be the only one to some object. In this >> case, the old GC would sweep it. > > OK, but in most, if not all of these cases, the objects are referenced > from the stack. For example, in the above fragment, the args[] array > is on the stack. Right? That args is a parameter call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd, So just from this I see only args itself on the stack, not args[0], args[1] and so on. I would have to look at all callers to determine that. Not good enough in my book. > >> Not using arg2 after Ffind_operation_coding_system above is not enough. >> It would have to be not using args2 after the GC has run. Maybe that's >> _in_ Ffind_operation_coding_system. > > OK, agreed. > >> Additionally, objects might not die but may move, assuming that >> SAFE_NALLOCA does not create an ambiguous root. So, using SAFE_NALLOCA >> makes another assumption in the MPS case: that something else prevents >> the objects from moving. Another proof or check required with my GCPRO >> hat on. > > What does it mean in detail "the object may move"? A Lisp object is a > tagged pointer. Do you mean the pointer should no point to a > different address, i.e. the value of a Lisp object as a number should > change to still be valid?=20=20 Exactly. Unless an ambiguous reference prevents the copying that can happen. > And if so, is MPS supposed to find all the copies of that value > everywhere in order to update them? So if I have several variables > which were all assigned a value of the same Lisp object, they all need > to be updated when the object moves? Yes. MPS does that with the help of our dflt_scan and its subroutines where we call MPS_FIX2 and update the reference. >> > 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? >>=20 >> Not sure, is the question why in MPS both pointers and Lisp_Object count >> as "references"? > > Yes, if that's the situation. Earlier you only mentioned pointers to > Lisp objects, something that happens relatively rarely. That's the case in MPS. Fixnums aside, Lisp_Object is basically also only a pointer, with some tag bits added. In that sense it's the same case. And every string contains a pointer to it's data, which I consider part of the Lisp data. And intervals are also Lisp data. The ones from enum igc_obj_type.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 17:50:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 12:50:07 2025 Received: from localhost ([127.0.0.1]:35059 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUUlL-00086N-CI for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 12:50:07 -0500 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:50586) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUUlI-00082m-UL for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 12:50:06 -0500 Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-386329da1d9so6274835f8f.1 for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 09:50:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736099398; x=1736704198; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=o2onSEU6cZW+pDoTYz+Kz6SKlWUKE5dD2kgcJyrgYEA=; b=HXP86kXw0GtErQsHu13nzKytKfByXMgrSgeMGyn5FTJxw4mZcrPsjogjx/hoqy+Q5H +CHuKBHDfD0Kq2EHtnTZyuF9Qb77wI/afb0yk/txFd3AvDvQtouyRPPynhxpCuBzRmAE s83gcX9nl1ppsOTko9q+9dWLJgKW5RiFjmWM/qS19qpKjaB83guj0mBUwxuK053xJm1y 8kigkKD3QGNgTs2Kx6p0tOaHGuQGXBrS8UlGjqcR7BfRp4WPYkoh4zxckGgbSqeB6jty IsUzmNfh5ZuN0mx/dLYxX1TiaaWn9TXhR64LUsiAbn0eaL/kpBgnvs8vIZyphQwa7D27 ql+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736099398; x=1736704198; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=o2onSEU6cZW+pDoTYz+Kz6SKlWUKE5dD2kgcJyrgYEA=; b=L6n21QynNj995fRTqlzu5rkG677GqerdrJu5C1qxXxCPMGEU88FP7EXlIwpoev2J+J +BGgS6xeq6NasN9Bn3ixAV/j5dHc74ZeQYT2YpUGaw/lhV6kJ3kxqbWdhXv9Hd7t8tLF z5TKWVpT/PrpAXUtksk8frWHDjL/CAXdT4CowHELrivzMXjhz8DIVjgIBtvb/JofIWJp NW4xcxOkP5jirJ0sCFZ+8SKFv8Ks7FzkG+eo1x4nzqWmudTIYnGNJ4foWwnDgmMgQvEN ti5qRP6dIFSBASDP5kg2YtjJ8Lxr+CBH/uRO961Tw5nm+8CXlA/82PRCrdXXmp+NfWY+ P9xw== X-Forwarded-Encrypted: i=1; AJvYcCX4hmKnyTVy6ukOVrC1+V8b5uMALGSlOT9vCHrPDvBVRrfvOVETgIXrfOq/UBW1wJzymhzaAA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwOM2enkswmQbHLg/Z3ylnkOXFVn/M2cmYl2Uss/+tPToJCp1Aw rZqQFbqCnuezHrsjibYpOBUwT/P35sETTO97JLkfjWIjKrvwRTssWu/Xgw== X-Gm-Gg: ASbGncsYhT/YQJjkfZZPX2etH6uzcajg7wdlOxBc0jB5KSZVQypR9CbgJoKs3cPTV8D IfGg/9IVNKrtlBwgGXE5p31ZJD+0GqLJGxFmL6jCoskZ8btb5N4xj8NcZdDWsjm/yMgjL2xRE6m FEtH1IiKSEmMz7XUEbTtzFpeEZ+7Xk8Yz4SegKQBCPvnkedlkCaNCe36aYhGMvFaaxRXbxctY6c P0HFlVminvkRiR1ASmCHjalPbYZI8E3wXa+53TyHLd2iLw+3RXPiPTzK94JbP4xkYTDcMj1hQGg UpMN7W4QaXvsEdaKBR0abAOfA3AH1xprDGD5FyFTMHdkS8N3ICYK0/DNoc5LD8G2AA== X-Google-Smtp-Source: AGHT+IHsA6SC4rU/FjEAi14eeNdCvYYq8wSxmI/sR1OVUXKQXJwUU2kA/Pk6JTzLlG1yC0bxMZNzPg== X-Received: by 2002:adf:a591:0:b0:38a:4184:2510 with SMTP id ffacd0b85a97d-38a4184257bmr21513923f8f.23.1736099397712; Sun, 05 Jan 2025 09:49:57 -0800 (PST) Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43661219a08sm549685205e9.25.2025.01.05.09.49.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 09:49:57 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <86o70l6ucl.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 05 Jan 2025 19:31:06 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <m25xmtwxt7.fsf@HIDDEN> <86sepx8sth.fsf@HIDDEN> <m2wmf9v9ho.fsf@HIDDEN> <86h66d8pnl.fsf@HIDDEN> <m2frlxv6d5.fsf@HIDDEN> <86ed1h8nji.fsf@HIDDEN> <m2zfk5tn0f.fsf@HIDDEN> <86o70l6ucl.fsf@HIDDEN> Date: Sun, 05 Jan 2025 18:49:56 +0100 Message-ID: <m2a5c5takb.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org >> Date: Sun, 05 Jan 2025 14:21:04 +0100 >>=20 >> Eli Zaretskii <eliz@HIDDEN> writes: >>=20 >> > So can we talk about the relative merits and demerits of using >> > SAFE_ALLOCA_LISP vs SAFE_NALLOCA?=20=20 >>=20 >> Let me add a (0): I assume that SAFE_ALLOCA_LISP is the right thing in >> the _old_ GC, because it makes sure objects referenced in the xmalloc'd >> memory are marked. From my POV, it would require a very good reason to >> use something else, which is nowhere mentioned. That's why I suspect >> it's a left-over from times where SAFE_ALLOCA_LISP didn't exist. > > This surprises me because on the master branch SAFE_ALLOCA_LISP either > calls alloca or xzalloc. So I don't see why SAFE_ALLOCA_LISP would be > safer in the old GC than SAFE_NALLOCA. It's only on the igc branch > that you made SAFE_ALLOCA_LISP make a Lisp vector. > But this is a tangent from my POV. I would like to discuss the new > GC, not the old one. > This in SAFE_ALLOCA_LISP_EXTRA (buf) =3D xzalloc (alloca_nbytes); \ record_unwind_protect_array (buf, nelt); \ makes a specpdl entry, which makes mark_specpdl do this: case SPECPDL_UNWIND_ARRAY: mark_objects (pdl->unwind_array.array, pdl->unwind_array.nelts); break; >> > And second, SAFE_ALLOCA_LISP conses a Lisp vector, which will increase >> > GC pressure, so isn't SAFE_NALLOCA preferable at least in some cases? >>=20 >> SAFE_ALLOCA_LISP allocates a Lisp vector, that's true. I think one can >> say that allocation is cheap on average. The overhead of freeing it is >> not copying it, which is basically zero. > > But I presume that if we have more Lisp objects, GC will happen > sooner, no? So increasing GC pressure is not zero-cost, because more > frequent GC means more CPU processing that stops our application > thread. I don't know what exact consequences that has. MPS is at least an incremental collector, so it's not normally the case that the GC _starts_ at some given point. What certainly happens is that the array is allocated from an allocation point which has a certain amount of memory pre-allocated. And that pre-allocated memory will run out sooner, in which case the allocation point will acquire additional memory, which potentially requires some amount of GC. And so on. So it will have some effect, for sure, but I don't remember the docs spelling out details. Maybe someone else knows. > >> SAFE_NALLOCA, with my patch, requires a xmalloc, creation of a MPS root >> object, deletion of that, and xfree. >>=20 >> Let's assume scanning costs are more or less the same because the >> number of references is the same in both cases. > > But more memory allocated via xmalloc doesn't increase the frequency > of GC, does it? Xmalloc no, but as I said above...=20
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 17:45:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 12:45:55 2025 Received: from localhost ([127.0.0.1]:35047 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUUhH-0007tT-3t for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 12:45:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35716) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUUhF-0007tA-1w for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 12:45:53 -0500 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 <eliz@HIDDEN>) id 1tUUh9-0004Am-AI; Sun, 05 Jan 2025 12:45:47 -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=pbMYh7S4SD6pzyYvjUWUV8aomKiMu4k/JXmEseiD7h8=; b=O0+JlhyhEl5FH9Yn6XA0 8YsERBuxna3s9m1S2ZTfe+C2lBYh+cPkf2wYv9y8BJpF95BKC6c4hpi7AM9FqlqDTvFuKf4F0mPAe XPVyKfVSJ8IlYTqF3awUlQfPxKF6GTFbmSUuG5uWjDF3ziFYgVFBwaRVdjpVDgX3MmDXU8r82Yfp+ WJ5bct8WsbWr2bsiDUVBVSYxT/OyS5WZKnBW/dFt7HUpuhpmXnZlWdhMyXbP7rNGmdz5ZWikcw2ei 8gTRTadrsBpr3Ld8LAA7lTSCZFAnrXJcOU+ak9cnNTIz+bKrLy/yHBiSsfmHjf04cti3E1uS4Goz4 SRRnc954umsVbA==; Date: Sun, 05 Jan 2025 19:45:43 +0200 Message-Id: <86msg56to8.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2v7uttkoz.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sun, 05 Jan 2025 15:11:08 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> <m2v7uttkoz.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org > Date: Sun, 05 Jan 2025 15:11:08 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > 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? > > Let me first say why I find this unsafe in the old GC, in principle. If > we don't assume anything about the objects referenced from args2, then a > reference in args2 may well be the only one to some object. In this > case, the old GC would sweep it. OK, but in most, if not all of these cases, the objects are referenced from the stack. For example, in the above fragment, the args[] array is on the stack. Right? > Not using arg2 after Ffind_operation_coding_system above is not enough. > It would have to be not using args2 after the GC has run. Maybe that's > _in_ Ffind_operation_coding_system. OK, agreed. > Additionally, objects might not die but may move, assuming that > SAFE_NALLOCA does not create an ambiguous root. So, using SAFE_NALLOCA > makes another assumption in the MPS case: that something else prevents > the objects from moving. Another proof or check required with my GCPRO > hat on. What does it mean in detail "the object may move"? A Lisp object is a tagged pointer. Do you mean the pointer should no point to a different address, i.e. the value of a Lisp object as a number should change to still be valid? And if so, is MPS supposed to find all the copies of that value everywhere in order to update them? So if I have several variables which were all assigned a value of the same Lisp object, they all need to be updated when the object moves? > > 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? > > Not sure, is the question why in MPS both pointers and Lisp_Object count > as "references"? Yes, if that's the situation. Earlier you only mentioned pointers to Lisp objects, something that happens relatively rarely.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 17:31:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 12:31:16 2025 Received: from localhost ([127.0.0.1]:35016 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUUT5-00079n-Pe for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 12:31:16 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46540) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUUT4-00079Z-Bl for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 12:31:14 -0500 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 <eliz@HIDDEN>) id 1tUUSy-0000le-IV; Sun, 05 Jan 2025 12:31:08 -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=PyjhHlkuQCVyDnEuXv/eSv/H9Gms/F0vNbAdAv5QRLg=; b=NRrxuIW2jgT3V5uzRHy9 PLOcUAw743QNjCzgWp6QQKzJQ0d5FbqsMFIZB0ZBm3i7GCF4F+6poQZ0q4sEQcxLHI3LZjZHA1XtK wcWYJcaLjYzVDyN5dCCLvP9tfeL1mRBOZUUG/J7sKnHHXfaXUE9tStExpM6yWiR6juFwQ95AuwX2Z /gxz1ijNVXZUygO36QBmwizEtzh44FiwNpNLAD/9Ukcjn9DccQH428bBlmNZL9r/KTWpgIX2EJsgY dfOeMXWHUlz0C0GQs+WUu3qhieINEMlCBJMI21OgoIUMr4F37xq711+/Sju1BANouiiJATqCtcAK9 CdJ3BE+RXN5xBA==; Date: Sun, 05 Jan 2025 19:31:06 +0200 Message-Id: <86o70l6ucl.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2zfk5tn0f.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sun, 05 Jan 2025 14:21:04 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <m25xmtwxt7.fsf@HIDDEN> <86sepx8sth.fsf@HIDDEN> <m2wmf9v9ho.fsf@HIDDEN> <86h66d8pnl.fsf@HIDDEN> <m2frlxv6d5.fsf@HIDDEN> <86ed1h8nji.fsf@HIDDEN> <m2zfk5tn0f.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org > Date: Sun, 05 Jan 2025 14:21:04 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > So can we talk about the relative merits and demerits of using > > SAFE_ALLOCA_LISP vs SAFE_NALLOCA? > > Let me add a (0): I assume that SAFE_ALLOCA_LISP is the right thing in > the _old_ GC, because it makes sure objects referenced in the xmalloc'd > memory are marked. From my POV, it would require a very good reason to > use something else, which is nowhere mentioned. That's why I suspect > it's a left-over from times where SAFE_ALLOCA_LISP didn't exist. This surprises me because on the master branch SAFE_ALLOCA_LISP either calls alloca or xzalloc. So I don't see why SAFE_ALLOCA_LISP would be safer in the old GC than SAFE_NALLOCA. It's only on the igc branch that you made SAFE_ALLOCA_LISP make a Lisp vector. But this is a tangent from my POV. I would like to discuss the new GC, not the old one. > > And second, SAFE_ALLOCA_LISP conses a Lisp vector, which will increase > > GC pressure, so isn't SAFE_NALLOCA preferable at least in some cases? > > SAFE_ALLOCA_LISP allocates a Lisp vector, that's true. I think one can > say that allocation is cheap on average. The overhead of freeing it is > not copying it, which is basically zero. But I presume that if we have more Lisp objects, GC will happen sooner, no? So increasing GC pressure is not zero-cost, because more frequent GC means more CPU processing that stops our application thread. > SAFE_NALLOCA, with my patch, requires a xmalloc, creation of a MPS root > object, deletion of that, and xfree. > > Let's assume scanning costs are more or less the same because the > number of references is the same in both cases. But more memory allocated via xmalloc doesn't increase the frequency of GC, does it?
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 14:11:16 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 09:11:16 2025 Received: from localhost ([127.0.0.1]:60430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tURLY-0005Go-Bi for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 09:11:16 -0500 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:61585) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tURLT-0005GW-8v for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 09:11:14 -0500 Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-43675b1155bso126862385e9.2 for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 06:11:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736086270; x=1736691070; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=9Cz4GIa4/uD4ib8Atzsgb1LB4SoegbDCRg+S4xPxd6E=; b=Kiv0ZN4T2haJP/SUsyqQTXc2X1gfJPg+CzUDqsQoap9NfBcDEoXNfiwD+rS1GrZmzS bWLFfABVopwOEyJNBm2d4oezakW80M0//CjAfIcAVMe+wjhe7IxTKI7uz123vZKCa4ah s1WHQb5tD4rt4m9qLairiARn6GyQ9noATw+hKW3YlZ4H0hUezLTA6mMtQ+2ncpIboRc3 dzVFv9rTk6EZNQYkos+u8/Q2ThM3pWPg9+6lVFlwf+bdTXybQoJjh+XUwF76zOiMxqFJ ckbb17H/ABa0u+05cural44onA9xUG0ELsoWrIjCs6+cHzTvSawl9brg6UvJPJCb4Jw7 lg3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736086270; x=1736691070; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=9Cz4GIa4/uD4ib8Atzsgb1LB4SoegbDCRg+S4xPxd6E=; b=UwSjvyiPMDUAgrAv5Tfs/sKcq5U9LxWVmBxm/sVu2Lb1stO6970xvYvp4DhB3s5eT1 rOwaj1/uwjw3nVmcTUFK5oTf19YEqYR5OyhYu1R3yZHRTucGvw7RixLKfB50PJdqdRW2 qDBwTrsxorIDmvAscwBFwqiH5jygmBbcByEZlCrTHTOPfZ1EkApOTioLGxoWH46RtJqG ToWI4PllPV5Wim5kS8CM8SZ7HnL4RCdgWsKNi6yXufMPd2K0otpQUWynBuLQhE56qYmg pJwSRO+QfZzx2ADfgaocuHV8CwRrYRsoin5xId7Ml14G/UN7qD+Mh61PFqT+wg+4vfpB 7ZJA== X-Forwarded-Encrypted: i=1; AJvYcCVDE7N34c0mIcM7cIGt9eB6wnaJJnM/ZzshGZuwEiBUor1j3/LJJ0RDTVwJsb6TgF7seaG6fA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yxu+C8eu6RifrAjGs4G8YvDHZgXWa/byBZJ7iJh8dS5d367MJqn zVIk3ooSQvSw5WbAJhRm7POjX5mBq7QczrHRmetYZD0f7i0leKeXcaN6Qg== X-Gm-Gg: ASbGncs/iIMpvhEhu+iO9uQ47gXPNS61nrAfcIS5/QG6PH10Xjp0lrrn/ZIY1nDykuP jUBi78PBGejYw4nRJoVI8ExPdt2nodFV8Mc1sCXOqgUcPhkEE3fYyQJHKzZjti4vea7krGMPDLi 28ZVQv6wn2qk3Y8n2nDQchFFyRPWrPJaaaqYsn2ngL8dcQBzBmbjmv+m39CP1KIlSMDr92tDYJu ifddx5eFXtXikkiYObquFxGZDHJb9bgisZP3GudjYCIDa7Kwk7JZvlzdQhs7qTXLwPoMXTMUoIR o5xvy0EegOw7jh9kD/8sEhunfeHO6fSfq26uuBUylYJ3/iVzyPNjVS7LYMoDjtTMYNlSbf3BF/f Q8Jnt2wd2 X-Google-Smtp-Source: AGHT+IG0w75GMyO3hC5kaP/QA/bce6l+J5WOY01/WQWmQ3L0s9nqXdTrBCS2aynXBLpMoubaHhP/+A== X-Received: by 2002:a05:600c:19cb:b0:434:f335:849 with SMTP id 5b1f17b1804b1-43668b93637mr450014825e9.29.1736086269532; Sun, 05 Jan 2025 06:11:09 -0800 (PST) Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-436611ea3d5sm544647825e9.5.2025.01.05.06.11.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 06:11:09 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <8634hx8k1u.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 05 Jan 2025 15:30:37 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> <8634hx8k1u.fsf@HIDDEN> Date: Sun, 05 Jan 2025 15:11:08 +0100 Message-ID: <m2v7uttkoz.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org >> Date: Sat, 04 Jan 2025 11:20:41 +0100 >>=20 >> 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. Right. If it doesn't use xmalloc, the references are on the C stack, and both old and new GC handle that by scanning the C stack. > 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?=20=20 Yes. > 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] =3D Qcall_process; > for (i =3D 0; i < nargs; i++) args2[i + 1] =3D args[i]; > coding_systems =3D Ffind_operation_coding_system (nargs + 1, args2); > val =3D 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? Let me first say why I find this unsafe in the old GC, in principle. If we don't assume anything about the objects referenced from args2, then a reference in args2 may well be the only one to some object. In this case, the old GC would sweep it. Or, the other way 'round, by using SAFE_NALLOCA we make an assumption. And that, from my (GCPRO) POV, needs a proof, or better yet some check in code. Not using arg2 after Ffind_operation_coding_system above is not enough. It would have to be not using args2 after the GC has run. Maybe that's _in_ Ffind_operation_coding_system. In the new GC, with MPS, the same is true as above. An object which is only referenced from args2 may die. Additionally, objects might not die but may move, assuming that SAFE_NALLOCA does not create an ambiguous root. So, using SAFE_NALLOCA makes another assumption in the MPS case: that something else prevents the objects from moving. Another proof or check required with my GCPRO hat on. > > 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? Not sure, is the question why in MPS both pointers and Lisp_Object count as "references"? If it's that, it's basically the same in the old GC. For example, when marking the C stack, we must recognize both pointers to Lisp_Cons and Lisp_Objects that look like conses, which contain such a pointer. Which was the reason I had to add the mem_blocks, the red-black tree and so on, to be able to determine if some potential pointer can indeed be pointer to cons, conservatively.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 13:30:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 08:30:53 2025 Received: from localhost ([127.0.0.1]:60382 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUQiS-0003DB-H5 for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 08:30:52 -0500 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 <eliz@HIDDEN>) id 1tUQiN-0003Cg-R7 for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 08:30:49 -0500 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 <eliz@HIDDEN>) 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==; Date: Sun, 05 Jan 2025 15:30:37 +0200 Message-Id: <8634hx8k1u.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2wmfag9s6.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sat, 04 Jan 2025 11:20:41 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> <m2wmfag9s6.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: pipcet@HIDDEN, 75322 <at> 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
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 13:21:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 08:21:15 2025 Received: from localhost ([127.0.0.1]:60367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUQZ9-0002h4-6r for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 08:21:15 -0500 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:42260) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUQZ7-0002gn-3i for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 08:21:13 -0500 Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4361b6f9faeso81575225e9.1 for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 05:21:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736083266; x=1736688066; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=bQNXoKgDv85+zoWmAs9nCWuxoqWJpOtF6vpCz8zt1P8=; b=VsWi+xy0h5QhMy5A6i/mdPNrox4pjiWK3/E3aFhuxDkwySIHpP88z3xsNZga/CTGoR WWk86f0StgVH+jvBLFa3p2gVZSkerk1KTs2b6+KmrBl4+f3XTKMAJ9t4Q9kpthA3anOX snsUglA1BmGNAMpc72GSTvYJ/M+oEY0XGiVAyfe7IMJVohdfeKoDHmQRObiCwLxVSdoK Y9PEtmRSIRYbLa8KuCGtnjNAsEUm3WSDuxHeDoYsmi7TFgNGB8qk7il2CNwrNSy6Qr2n 0zhYkDMoAoGoccaVoP/463VDrJcDEU0lZd2/UIWD0beSGuViig2o2y8AYOs8vTpINk9r 17KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736083266; x=1736688066; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=bQNXoKgDv85+zoWmAs9nCWuxoqWJpOtF6vpCz8zt1P8=; b=fcUJXmLOS7wcF20icjdgtuFGYcAnoEtNAQzXFIk+1NTA0wbsdMVTqgNx/HrWoi5iMF NEOItpobcVNxTkP5xTsb3LcxLFF6UAouKJ1oPYi8S1XZbvbp2xmw1DKilnzSvE5Gzm6N BT/qJ772rx6tiba6IqovH7GYExuuvALQzQXqMO7nMDz5dM06YVJZ6TD1r0xU7tnByK/c u8YUb1BdnHhOsLwov3OLjR/t96UW13cNHAhmJ1okb3ecb4yLuR/6kHvCe3TVv6ZcFOyx me+wjoANtch493XazuDiHFllP+w7utDziEd8fHwBPsyWhTpS0SDTJVYDtx/h1IRXJyjG wtyg== X-Forwarded-Encrypted: i=1; AJvYcCXc2YDsrdWj7aP2h+y2z1SxrBx1M01Rcw+o81ZX2cKBDY7mLcjDvGYDBRgWd+i3WLespbUJhA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwpttG6ZQdlegfHiNJftgTE7WUzV1Ld6oCUDWhpEnpRJngGUxKJ Xm5269kSstZqb9ItUGD0bGpHXu9gThLyobBjfvltxcokytORF6fjUadUJw== X-Gm-Gg: ASbGnct1yxmd0SsbsH5LfB8RnwA/9SChuO5QFo6sayPqPp7S+py94AGAQAllZRFhnc0 +rLV56FCfNBJ/cdgkcSsTtcF95UOX4eykRgCkbFYT+o0MNao2vijd1uB/fIpLh2wpSqWjr9KCX5 0DQVYSi/1ON1rBOHdMknSkKC/KZGpeGD3WrgqJjS2ygFZsJrT5ftXi5kL7XKS4Ahlq+3P+vidij uznftzDyJtUqXqRgSowlgBfj9WrxTV+8KC7Zki+L7VjDNE8CqSqfqykeAPhK5+wg8zjb11NTt17 5vPsC2RHUpTrSfuNlkY70LBB2OOlkysJC+U0esnuWPO5JqiJh0MO2ZU+vTNnFNIn8g== X-Google-Smtp-Source: AGHT+IG9xQ9xny4THkfsiWrdJqO4YsfAr0zBNGTusXPkRGcqBGKZJI8qw59WpGz/J+hdYL876x72DQ== X-Received: by 2002:a05:600c:4f4f:b0:434:fc5d:179c with SMTP id 5b1f17b1804b1-43669a25fb4mr467186605e9.13.1736083266231; Sun, 05 Jan 2025 05:21:06 -0800 (PST) Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43661219a08sm544271725e9.25.2025.01.05.05.21.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 05:21:05 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <86ed1h8nji.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 05 Jan 2025 14:15:13 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <m25xmtwxt7.fsf@HIDDEN> <86sepx8sth.fsf@HIDDEN> <m2wmf9v9ho.fsf@HIDDEN> <86h66d8pnl.fsf@HIDDEN> <m2frlxv6d5.fsf@HIDDEN> <86ed1h8nji.fsf@HIDDEN> Date: Sun, 05 Jan 2025 14:21:04 +0100 Message-ID: <m2zfk5tn0f.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org >> Date: Sun, 05 Jan 2025 12:37:42 +0100 >>=20 >> Eli Zaretskii <eliz@HIDDEN> writes: >>=20 >> >> If you mean the two patches I sent with "these two", then no. I prefer >> >> using SAFE_ALLOCA_LISP because that introduces an exact root. >> > >> > I guess I'm confused, then. The first patch replaces calls to >> > SAFE_NALLOCA by SAFE_ALLOCA_LISP, the second patch modifies >> > SAFE_NALLOCA to call igc_xnmalloc_ambig. That's why I thought they >> > were alternatives. >> > >> > If they are not alternatives, then why did you replace SAFE_NALLOCA in >> > the first patch? >>=20 >> I checked other uses of SAFE_NALLOCA that were not yet mentioned, and >> found another problematic case. (Something with struct itree_node *, >> don't remember the function name, it's in some other mail). There were >> too many grep hits for SAFE_NALLOCA for me, so I shot with a canon :-). > > OK. > > So can we talk about the relative merits and demerits of using > SAFE_ALLOCA_LISP vs SAFE_NALLOCA?=20=20 Let me add a (0): I assume that SAFE_ALLOCA_LISP is the right thing in the _old_ GC, because it makes sure objects referenced in the xmalloc'd memory are marked. From my POV, it would require a very good reason to use something else, which is nowhere mentioned. That's why I suspect it's a left-over from times where SAFE_ALLOCA_LISP didn't exist. (And I very much hope it's not the old pattern of "I don't need to GCPRO this because I know this is already protected because of so-and-so", which you might still remember from the old times. In which cases I would've liked to hit people with a GCPRO on their head when I had to debug that and so-on-so was no longer true :-).) > First, why is it better to have an exact root than an ambiguous root? In the most general case, where an ambiguous root can contain random bit patterns, say the C stack, I'd say the greatest advantage of exact roots is avoiding false positives that keep objects alive, or prevent copying them. In the specific here case, where a root actually contains only Lisp_Objects, and not random patterns, I'd say the advantage of exact roots is that they don't prevent copying. The "prevent copying" disadvantage is a bit hand-wavy, and depends a lot on the GC implementation. Maybe a good picture of it that one would like to have a fully copying collector, with its advantage of reducing fragmentation, for example, but one can only have a mostly-copying collector, because of ambiguous references. The more the "mostly" is true the better for the copying/fragmentation. Does that make sense? > And second, SAFE_ALLOCA_LISP conses a Lisp vector, which will increase > GC pressure, so isn't SAFE_NALLOCA preferable at least in some cases? SAFE_ALLOCA_LISP allocates a Lisp vector, that's true. I think one can say that allocation is cheap on average. The overhead of freeing it is not copying it, which is basically zero. SAFE_NALLOCA, with my patch, requires a xmalloc, creation of a MPS root object, deletion of that, and xfree. Let's assume scanning costs are more or less the same because the number of references is the same in both cases. I think SAFE_NALLOCA is more expensive,
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 12:15:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 07:15:23 2025 Received: from localhost ([127.0.0.1]:60245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUPXP-0007Zq-0i for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 07:15:23 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:41864) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUPXM-0007ZY-Kb for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 07:15:21 -0500 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 <eliz@HIDDEN>) id 1tUPXH-0000KC-7r; Sun, 05 Jan 2025 07:15:15 -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=Yr9VDYnlgg1W/bn+d1aDTVoQxjvmR9yE6NCF9cuUvOs=; b=CplT53oL6Q03nf1yDYa3 hfb5us0c+fsLrqsByJhBjYu+dYESco47O0pnqDPaagZylbZxipdlXKgEZ7xeNiJ3yY6v5yYM4QlXl C27KxdjCb7V69EPftGlGJEUhHrB5Uz4/qLIEN4hp+7tQ4jVyeIluTBt1KIEDk5aNvQicZp4qRWiGc E6ItNvjPMrnL9rPHC/Dfx6y6ar1WNg+2gdS4tUipsMtAqPzqEjgXZ133gTjvAywIsn3ZNs5QHEm6o PEGsl3vSMFewd/8mOODNlGO4j8T3IxS/EYcuyBaFcRVy8lY1FhcPvCJ+WGeoeoxCFAIVPy/iv9Y4R V4kF+mcrTtgV6w==; Date: Sun, 05 Jan 2025 14:15:13 +0200 Message-Id: <86ed1h8nji.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2frlxv6d5.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sun, 05 Jan 2025 12:37:42 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <m25xmtwxt7.fsf@HIDDEN> <86sepx8sth.fsf@HIDDEN> <m2wmf9v9ho.fsf@HIDDEN> <86h66d8pnl.fsf@HIDDEN> <m2frlxv6d5.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org > Date: Sun, 05 Jan 2025 12:37:42 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> If you mean the two patches I sent with "these two", then no. I prefer > >> using SAFE_ALLOCA_LISP because that introduces an exact root. > > > > I guess I'm confused, then. The first patch replaces calls to > > SAFE_NALLOCA by SAFE_ALLOCA_LISP, the second patch modifies > > SAFE_NALLOCA to call igc_xnmalloc_ambig. That's why I thought they > > were alternatives. > > > > If they are not alternatives, then why did you replace SAFE_NALLOCA in > > the first patch? > > I checked other uses of SAFE_NALLOCA that were not yet mentioned, and > found another problematic case. (Something with struct itree_node *, > don't remember the function name, it's in some other mail). There were > too many grep hits for SAFE_NALLOCA for me, so I shot with a canon :-). OK. So can we talk about the relative merits and demerits of using SAFE_ALLOCA_LISP vs SAFE_NALLOCA? First, why is it better to have an exact root than an ambiguous root? And second, SAFE_ALLOCA_LISP conses a Lisp vector, which will increase GC pressure, so isn't SAFE_NALLOCA preferable at least in some cases?
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 11:50:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 06:50:03 2025 Received: from localhost ([127.0.0.1]:60204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUP8s-00065V-OQ for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 06:50:03 -0500 Received: from mail.cs.ucla.edu ([131.179.128.66]:43656) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eggert@HIDDEN>) id 1tUP8p-00064j-UH for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 06:50:01 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id DD3D03C082EB5; Sun, 5 Jan 2025 03:49:53 -0800 (PST) Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP id D-jMpmC-flae; Sun, 5 Jan 2025 03:49:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.cs.ucla.edu (Postfix) with ESMTP id 8BAC73C03E9EF; Sun, 5 Jan 2025 03:49:53 -0800 (PST) DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 8BAC73C03E9EF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu; s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1736077793; bh=+25AaArOn2Q/3DMb9cnJBoc6jzX05WUll1bYVD794YI=; h=Message-ID:Date:MIME-Version:To:From; b=DvlbA2m7tYAgbU30KpFh0uK0sQpU1UTnHHaH8UnfJnR4/oVRh33iLGWUi75Q3bTze Dxipf04YEmP5x3LNqfGGRLoVkFuiJ7mVhpCV671fc91LabjzvptPqqPfOPoIvRpSsN KyUAJprrPEjxI5V9aMNuk5UXBZJqEGWEEC+Rx9GmeQNjeAUXF/GpkUPnuXfKp1dfvL HZf9OD+qaopeYzgmXVYYxja3UwkYlcvEvA/YBDlcC8yRyaNF0OO9qj1I/T6lYicq4u j0dpKMOIWhR7Gr1M8aNZPStwpjI3sGMRTSdTSwQFf0asNnxz5USYCxFTZ9LKIlgDD8 fr0/cbKSkAYFQ== X-Virus-Scanned: amavis at mail.cs.ucla.edu Received: from mail.cs.ucla.edu ([127.0.0.1]) by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id h7RiKZ0iiXRL; Sun, 5 Jan 2025 03:49:53 -0800 (PST) Received: from [192.168.254.12] (unknown [47.154.28.214]) by mail.cs.ucla.edu (Postfix) with ESMTPSA id 6CF943C0031DF; Sun, 5 Jan 2025 03:49:53 -0800 (PST) Message-ID: <70e8e902-1e7e-4c6d-82bf-a69ac641d6cb@HIDDEN> Date: Sun, 5 Jan 2025 03:49:53 -0800 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) To: Pip Cet <pipcet@HIDDEN>, =?UTF-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <865xmtaeh9.fsf@HIDDEN> <m21pxhwu4a.fsf@HIDDEN> <86r05h8s9d.fsf@HIDDEN> <m2sepxv90i.fsf@HIDDEN> <87a5c5cxso.fsf@HIDDEN> Content-Language: en-US From: Paul Eggert <eggert@HIDDEN> Organization: UCLA Computer Science Department In-Reply-To: <87a5c5cxso.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: Eli Zaretskii <eliz@HIDDEN>, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) On 2025-01-05 03:21, Pip Cet wrote: > is it always unsafe to use an SDATA obtained > before a GC run after the GC run completes, or is there a more > complicated set of rules? If there's a more complicated set of rules, I don't know them. Gerd's citation of pin_string makes sense.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 11:37:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 06:37:52 2025 Received: from localhost ([127.0.0.1]:60177 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUOx6-0005SA-4C for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 06:37:52 -0500 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:61807) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUOx4-0005Rj-JL for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 06:37:51 -0500 Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4368a293339so100542065e9.3 for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 03:37:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736077064; x=1736681864; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=MVPEK1xlkXOouZ/Zh8F1NztEF7niicdHtq6Sl9zEHjU=; b=npSszkh2FLbdGv8DzoYZDnOHZmC6JQS1BAcPWNE3FEaJ2Jn/kzMHczKNvBIEExkDZS XmtpX33xLE/z5GCN4rzqr98mkB97XzIaQ+dq1IdgMBTB5hCPmwgBQM81+1ZD2za2d7bJ eeVLu9hOVHVVSTYoSWOL2yvcYABXhQ25VIIwlQrPBKu2xsfXIHTgZxWxyF88ZSvRSvQD d5SxLaD14euUklj2zM66NruYkYiSvcN+7yUwPtUDX80mkAJ7065U+XFjapZ4xV8uB2lQ NZWvh92yNMSwo1DIqw5EQOTCkYZBpQ6r4/faOtJUcb+oOGkzxhPJGO3yozaJzla2nhOO 0bPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736077064; x=1736681864; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=MVPEK1xlkXOouZ/Zh8F1NztEF7niicdHtq6Sl9zEHjU=; b=IBWmbYFe7ctGdecqyTotHpAq2gOlcBcG8CPbFIl1sX2HQJnsESvphmsvzlce6TyzIZ NpE+njzGVV6aktlPa9wB53/A/SaEuPwrhPkAHZQBlsuO8UIfBVZfw3TX5CZzzASnRfxY GZzckSwkCKDpRTfTuEk93ngFiDTDuQb/JO7qq3pSBT4qy5O/UkW+YfG5i4bL/eRvHM8x /B8xquhncJ4yVNXCQOisA65nH/wbtcuzxSUcrx7bV1uZqN95ecwjiCY3Wqx9YB4VJKCj 8aTKwb/V2Zbwn3XiRNxyRCHhSOvcN9bXApP00hoOsv2q1kDnUue5Tloo6brnN/Cu4QHf 1N0w== X-Forwarded-Encrypted: i=1; AJvYcCUHbTgpJECQtCBna7H/O2V/95Q1GsqEinX98u+pKwDGETMrmpC/W0+ossG7b2PeNVBtPy+ZJw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxmOqF/v7BOEahY3E0aF34nA3A3XzzyZDXWqR3B2zZ0IGYt0GlU h3XSytX5rMmdXU53h3UQ8JrtLtgh/V8EX5xHvLa8Y1momPQ/tRxJyO/XOw== X-Gm-Gg: ASbGncu1VLWlBJl4n+EI4w95lsedI8pztA5I/JZ5h0uQqDE6cV4eajR73CzTmqEZQTZ kyoYUgKa7tcuQ0bkCrLtFbYcnyhR29qJ/TTq5njrW8zNfu28cOfkjBYtd0W6gsnvfF8EpyTeEj7 VFVrdUnV3IzhoyvxKS0rJLWpQ4o7uWRR/HjCJIDqCDOFU+Ppyk20tBdC/oH7TMik4n8dDdhPT7l ftux1N3zabgYdBVCUue3e0NFFVwZEL7cHOGh80ftgSp7+fOOrDs8Cpb80a8de9D52Pgghc+XYiG CNgtEodN7y6anw6pCxUarzxLvk943ESv6KGlv2eF75gXLn05LlZbw4SE8OecwU9Srw== X-Google-Smtp-Source: AGHT+IE5fhuZv7dm2lN8qsMMwCd5SOrr+QSnf4aTqEPMaQSOjQLLJA5WoN7xa2k1yhav7EE8ojrSdQ== X-Received: by 2002:a05:6000:1565:b0:38a:1b94:ecc1 with SMTP id ffacd0b85a97d-38a221f5e39mr44171306f8f.25.1736077063795; Sun, 05 Jan 2025 03:37:43 -0800 (PST) Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c828e7asm44910481f8f.21.2025.01.05.03.37.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 03:37:43 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <86h66d8pnl.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 05 Jan 2025 13:29:34 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <m25xmtwxt7.fsf@HIDDEN> <86sepx8sth.fsf@HIDDEN> <m2wmf9v9ho.fsf@HIDDEN> <86h66d8pnl.fsf@HIDDEN> Date: Sun, 05 Jan 2025 12:37:42 +0100 Message-ID: <m2frlxv6d5.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> If you mean the two patches I sent with "these two", then no. I prefer >> using SAFE_ALLOCA_LISP because that introduces an exact root. > > I guess I'm confused, then. The first patch replaces calls to > SAFE_NALLOCA by SAFE_ALLOCA_LISP, the second patch modifies > SAFE_NALLOCA to call igc_xnmalloc_ambig. That's why I thought they > were alternatives. > > If they are not alternatives, then why did you replace SAFE_NALLOCA in > the first patch? I checked other uses of SAFE_NALLOCA that were not yet mentioned, and found another problematic case. (Something with struct itree_node *, don't remember the function name, it's in some other mail). There were too many grep hits for SAFE_NALLOCA for me, so I shot with a canon :-).
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 11:29:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 06:29:45 2025 Received: from localhost ([127.0.0.1]:60152 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUOpE-0004yY-PZ for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 06:29:45 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56312) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUOpC-0004yI-JO for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 06:29:43 -0500 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 <eliz@HIDDEN>) id 1tUOp7-0004mV-0V; Sun, 05 Jan 2025 06:29:37 -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=86ZFKaFd58HtNLXMFamwBu3H3mnHFoqyRFzCcensGXg=; b=Rtma5o5+h7NZWtvkR0Yb um4ISqQWqvWV5EEC23N+E7PQg4AUkWjZnMM80EZ5y/en+YRRQdunvyug+84a5oMTs9XzGutfQAljE j+HAlEgylcUaXgVCxZ37RCQAsJ5Xu14kUpR3LCfj2I3mPe/hFiiTeoPub1d6pryLLnyRMOVD5G/xP rToGJzwYhzZkPbFlAFPjuePCaUxtObn3BI2G2H/xQGs9G0CNUcrS6LtuFkcVx+h9W79u/QIJlmcgX jVeRn2WUoAH0dk8JiekTxDW3rpH9sNu9t910X/t0wjopa5/KiR1/2AY7TKNHlrhgKF0MC0EnqBCfy Fl8qXO3fsHz6oA==; Date: Sun, 05 Jan 2025 13:29:34 +0200 Message-Id: <86h66d8pnl.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2wmf9v9ho.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sun, 05 Jan 2025 11:30:11 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <m25xmtwxt7.fsf@HIDDEN> <86sepx8sth.fsf@HIDDEN> <m2wmf9v9ho.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org > Date: Sun, 05 Jan 2025 11:30:11 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> Cc: 75322 <at> debbugs.gnu.org > >> From: Gerd Möllmann <gerd.moellmann@HIDDEN> > >> Date: Sun, 05 Jan 2025 07:59:32 +0100 > >> > >> Gerd Möllmann <gerd.moellmann@HIDDEN> writes: > >> > >> > Just want to add that all SAFE_NALLOC uses should be checked in > >> > scratch/igc. For example, set_overlays_multibyte uses it to store > >> > itree_node *, and itree_node is in MPS. > >> > > >> > I think I'll just make it allocate a root in my Emacs. That's the least > >> > work. > >> > >> Please find attached what I'm using now in my Emacs, in addition to your > >> xstrdup commit. > > > > These two are alternatives, right? IOW, we should use one or the > > other in each specific case, is that correct? > > If you mean the two patches I sent with "these two", then no. I prefer > using SAFE_ALLOCA_LISP because that introduces an exact root. I guess I'm confused, then. The first patch replaces calls to SAFE_NALLOCA by SAFE_ALLOCA_LISP, the second patch modifies SAFE_NALLOCA to call igc_xnmalloc_ambig. That's why I thought they were alternatives. If they are not alternatives, then why did you replace SAFE_NALLOCA in the first patch?
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.
Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 11:27:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 06:27:43 2025
Received: from localhost ([127.0.0.1]:60144 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tUOnH-0004uZ-5w
for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 06:27:43 -0500
Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:50299)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>)
id 1tUOnF-0004uJ-RA
for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 06:27:42 -0500
Received: by mail-wr1-x42a.google.com with SMTP id
ffacd0b85a97d-38a25d4b9d4so4873533f8f.0
for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 03:27:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1736076455; x=1736681255; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=1sYlm6LGu0RInBt8qOtU36rnahVethxSqkFJGcmRMXQ=;
b=MHXeLq4jsdtSvFF8adKxObHCH5n5DS+z+q48RSnHlyRPRIoLsqRzWSe1VyOwWpMtfH
1oohKuHQ+bOtWTQ/WaGSFzAEzhP0BbrRDVzev7Qizw10usqJX5uuLiIPYZHTP4abcTJ6
W8a3wr+15Buoq1fhoU55BX7O1KQu8Xjlkd+iGTiaf+Z9pPOT6med1QmpEnehziT69omA
e3BFdM9PrjGJLM+qemyqyq5rnStTGR5Pxj7sZLY65XMX6Gc2CR5KSCS/PelF5px46WyS
OClMAGnuUACR4HGdTONY+xtQDpTZ690qvfl3qLmEuRAgPVjeCrsMN6KLsEcw2jikOCn1
rI6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1736076455; x=1736681255;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=1sYlm6LGu0RInBt8qOtU36rnahVethxSqkFJGcmRMXQ=;
b=CHoCzaUDwG0fLh8FFe+W4Wy3u6Q4t/gHL7i1YlwHQERrX7XU7SrJgAMz3kB82P4XoO
47d3ubGrO1OOz0oIruaDQpZo2i9N7LVXC1Ux5WUatOo8tvpwpd2f3djtgdHnhBmS6vKj
NaQUFI4Jmgj2Omq6Whi2erBa8u8aOaioFfvJ9Vs8qxqatabcTfikqLYzoRWNi8Iv2OD3
02TSnzFvTLTmiBb5dlUXSBnWbhSDlmFNIEKwf7OxRd/7IDCFhOYPOVe+EYuquePWMcro
8/OQCHZIxUfwZa/CTdc5QtqxnbwM2cXyo4SMnORTsyi0td2JrWKvnLdKjLtFwf4L/SjT
+ZAA==
X-Forwarded-Encrypted: i=1;
AJvYcCVFO3w0cacy0+lok+29k8NJ4wk6vth2hkjD9GKMxQM4HHL50v43iVjupGhsEzQNtdRLlj4/Bw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yzrbgb4fHmvZogKqL5shvyamxg/vFAGrVAxWfV53kkZ3fj5QcQo
mj0AojpVKmZ0lWTRij0XQ34PKvJO1x40UAmukigsvOI0UYK4WDzZ5Hr3qA==
X-Gm-Gg: ASbGncuqe2BEx0AoMLUa506w02UiMIVTRtgE78WDrKhjf9LMJ/ttoJQHXZaflKBQhR2
BBQQb73aopLw7yy36uJWw3YSTJkGOq3dd/tBrBVNl+NijdSnBfKdSfihmjeEWh4wAYXAwoCyh75
6AAoNfSnYtaMGasd/xNoH1HHUIUhWW61L44tWbny22Zjq5u4gnnfrA7moxQoUWJ6WAnbwy/zS6j
ao6MC89FJqBpcp54OS2D8EfGzzowioZYvZtxRap0AkMKlXM8JIdbcp2uXdQOHpXV6pG6EuTVWME
bQGIU39wfpjvWABX6T4wgPWsbjcQX/8ZZ2SScyw64oPLsyMsdSe0mzREmFN0Zu7Lww==
X-Google-Smtp-Source: AGHT+IHCHOsTEJNMUR+CHdz1Mc2gqgYi4JkOD0w28Nh7tHFzJdRBiUxytRaRuaoV9JcEKUEs0285cA==
X-Received: by 2002:adf:890a:0:b0:38a:615b:9ec0 with SMTP id
ffacd0b85a97d-38a615b9ff8mr10827530f8f.54.1736076454869;
Sun, 05 Jan 2025 03:27:34 -0800 (PST)
Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de.
[2003:e0:b747:5000:78d7:74d9:8599:11e7])
by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-38a1c89e1c0sm46122366f8f.77.2025.01.05.03.27.34
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 05 Jan 2025 03:27:34 -0800 (PST)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
In-Reply-To: <87a5c5cxso.fsf@HIDDEN> (Pip Cet's message of "Sun, 05
Jan 2025 11:21:17 +0000")
References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN>
<865xmtaeh9.fsf@HIDDEN> <m21pxhwu4a.fsf@HIDDEN>
<86r05h8s9d.fsf@HIDDEN> <m2sepxv90i.fsf@HIDDEN>
<87a5c5cxso.fsf@HIDDEN>
Date: Sun, 05 Jan 2025 12:27:33 +0100
Message-ID: <m2jzb9v6u2.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75322
Cc: Eli Zaretskii <eliz@HIDDEN>, Paul Eggert <eggert@HIDDEN>,
75322 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Pip Cet <pipcet@HIDDEN> writes:
> However, I don't fully understand which additional protections
> traditional GC offers: is it always unsafe to use an SDATA obtained
> before a GC run after the GC run completes, or is there a more
> complicated set of rules?
There is this, which is used in the byte interpreter, IIRC, as sort of a
workaround for the problem
#ifndef HAVE_MPS
/* Pin a unibyte string in place so that it won't move during GC. */
void
pin_string (Lisp_Object string)
{
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 11:21:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 06:21:29 2025 Received: from localhost ([127.0.0.1]:60131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUOhE-0004bz-N6 for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 06:21:29 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:43451) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tUOhC-0004bg-KL for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 06:21:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736076080; x=1736335280; bh=ocjUZHWk25PwxCC/JThgUSMXihaM8Q3x4QkWimOgikg=; 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=gsipMHP8vnF5JXWd9y5QgLnqgiCm5E+3cen2XEy4xc5XUfQF1Fitrg6JSl2qz8oXI Ud9ItIc8RizleS8mAXTkqqntjiZfSAVOwCCQTCJu3dTCcGUucrOU12thKpee+h8b10 gDywSw90LowLsefGlLWbHIZTrYkKXzl4VgJex39de97Zmta6WghJ2luzPHv6chu9EJ lNW9fHl9flwHOdTwGOllFcMhuBFaPfqq0K/25gI1CequTZWaiJhpzp663HX1HPj8QW FlIK1UgwprdqS8Zc1b4nqqMC9ePjWuSC+t3otFjuN86/1i+34ymBgxcXI/zX3knOW+ DMJbL6aiWPM+Q== Date: Sun, 05 Jan 2025 11:21:17 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Message-ID: <87a5c5cxso.fsf@HIDDEN> In-Reply-To: <m2sepxv90i.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <865xmtaeh9.fsf@HIDDEN> <m21pxhwu4a.fsf@HIDDEN> <86r05h8s9d.fsf@HIDDEN> <m2sepxv90i.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 796f9c242dcf6e90652f80dc516208f2acfee41e MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: Eli Zaretskii <eliz@HIDDEN>, Paul Eggert <eggert@HIDDEN>, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > Eli Zaretskii <eliz@HIDDEN> writes: >> MAX_ALLOCA is only 16KB (and Paul Eggert says it's dangerous to make >> it significantly larger), so I'm not sure your assumption about >> negligible performance impact is necessarily correct. > > Works well for me so far. Paul, this discussion is about changing SAFE_ALLOCA so its memory area is scanned conservatively for the scratch/igc branch, even if xmalloc is used (when there isn't enough stack space). MPS requires this in some cases where the old GC didn't, because it's enough for the old GC that we know there is a reference to retained objects elsewhere, but MPS might move the data in that case. However, given how rare it is for SAFE_ALLOCA to use xmalloc, maybe it would be a good idea to make the corresponding change for the old GC, too? Also, scratch/igc behaves differently with regard to SDATA: references to string data will keep the string data (but not its metadata) alive. If scratch/igc is ever merged and people start using it exclusively, we may start seeing bugs that rely on this additional safety guarantee. My preference would be to change the traditional GC to also ensure code like char *p =3D SDATA (string); string =3D Qnil; garbage_collect (); puts (p); is safe. Some memory and performance cost, but no-GC assumptions are hard to verify. This may or may not fix bugs in the present code. A potential example for such a bug is this: I think that it's possible for call_process to call Lisp via ENCODE_FILE in a very unusual scenario, which might trigger GC and relocation of string data which has already been put in the argv and environment arrays. However, I don't fully understand which additional protections traditional GC offers: is it always unsafe to use an SDATA obtained before a GC run after the GC run completes, or is there a more complicated set of rules? Pip
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 11:04:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 06:04:49 2025 Received: from localhost ([127.0.0.1]:60085 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUOR7-0003fb-2u for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 06:04:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34030) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUOR4-0003f9-Uy for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 06:04:47 -0500 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 <eliz@HIDDEN>) id 1tUOQy-0005gg-Uj; Sun, 05 Jan 2025 06:04:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=pNjkTq/efNlcieYm+ff4Xou2Ycq2oMSXBh/Q06WUQ2o=; b=q8mnxpFw194k MQRCxZjOwEVInfrKRpMBQ/+3PBuqxmySqmEYEI90ddXNJbxsbrajYIB4fHsJnkHtmzWk7LmkR4cz0 Ort2YY81BMe6Pz8W9Av09oJXSONQFN3XVPPwDkP6b7VjozE8v7/Fty5iUuR/pF10B3vpp6gBdCwpT N1TiC/9dkakMC4VVl4l8sVnr/tQplUIfs6Ft7PZjpuvpq8HEVVFrkFUFS0LOrgDD5IALUNvx+a4Of qHVBKa2Xen3z3ZQhicIHlnBlfn1ZFl6Ky8m8B/mbyZhZ0u4ySt3px8iIeh5epwrMQ9F1MWDQyrsrl EDNIKMdvkyapavCyc6EAMQ==; Date: Sun, 05 Jan 2025 13:04:37 +0200 Message-Id: <86o70l8qt6.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87ttadd25l.fsf@HIDDEN> (message from Pip Cet on Sun, 05 Jan 2025 09:47:06 +0000) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <877c7aha9n.fsf@HIDDEN> <86y0zqbgot.fsf@HIDDEN> <87ttaee5qp.fsf@HIDDEN> <86a5c6b9sb.fsf@HIDDEN> <87ikque0xp.fsf@HIDDEN> <864j2dacuz.fsf@HIDDEN> <877c79eipq.fsf@HIDDEN> <86ttad8v37.fsf@HIDDEN> <87ttadd25l.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sun, 05 Jan 2025 09:47:06 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > I don't suggest to avoid GC. I suggest that where GC _can_ happen, we > > must reinitialize the pointer to string data after GC. > > That suggestion is incorrect. MPS GC can and does happen while we have > SDATA pointers on the stack, and we rely on it to keep those valid. Since we've established that MPS works on a single thread, which is our Lisp thread, then GC cannot happen unless we make some call that could trigger MPS GC. Thus, whether or not SSDATA pointers are on the stack is not relevant to when MPS GC could happen; what matters is the code that is executed. > IOW, MPS treats SDATA point the same way it treats Lisp_Objects. I don't understand what that means. What is "SDATA point"? What is the meaning of "treats the same"? > The problem is that like Lisp_Objects, SDATA pointers cannot be > moved to xmalloc'd memory and retain their validity. No one said they could. This is trivial. > As long as you think MPS requires us to avoid GC in this case (this is > implied by "we must do this or that after GC"), your understanding of > how scratch/igc uses MPS is fundamentally incorrect. Maybe my understanding is incorrect, but this style of "discussion", where you are working hard to prove at all costs that I misunderstand the issues and to point out my mistakes, contributes nothing at all to understanding. It only contributes to confusion.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 10:45:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 05:45:37 2025 Received: from localhost ([127.0.0.1]:60058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUO8W-0002k1-Oc for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 05:45:37 -0500 Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:60738) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUO8U-0002jq-RI for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 05:45:35 -0500 Received: by mail-wm1-x32d.google.com with SMTP id 5b1f17b1804b1-4361f664af5so153245805e9.1 for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 02:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736073933; x=1736678733; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=nLDfioJAM0nLcRnykTOOpFYccHJMtVDdEdmaje4F4HY=; b=CEMdI9NlkXJZUdz1IZBjUOsJMlm9BsoetICr4iqY/72R9+7StTCVHeIKcUII1NWmdH efUr4qkG4G6AJjfTySTIGHM6MfVm4waMBHa3sqoLAEqywWCWNzNNZHeR/BC5kY5ybvBe snP/AMEBB10pK/fBv8f3O0fGci+jO8dEukyocUODcwRZSiPI3wtGgiTqhU7QnVwyT1fD GxXw0hE34V6+ofEsfac1QDTh+G+NOR7o8yC+17+ZwWdjpeADW+MSMOXwLXqTPPxagkXj 7kujGbigCQ1Hda1dlLtFkFLzroDMv73O71wTNuECBPq+CIlQIAyHX9vLrjJ2Ew3WTtIu IYMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736073933; x=1736678733; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=nLDfioJAM0nLcRnykTOOpFYccHJMtVDdEdmaje4F4HY=; b=AaFGrSXt5jKV1pJdk9/yCXx9otelmScf83sYZ9tgp/+lzmH28a+KebL2cs6NRzUMgI r4l82OElxFxnpbWB11hxJlRg5DfQYbLxMs9OWgwvWMpC57nZKnYU62T4Gky3niiGXKUl FA/Ar7F3X54ke64IhjP8My4ynB8eoo2vtREO8biw6gSqnGhsIUN31yE9vmuQ6XPTRO9B eGaeWnDxf1bLXWhraeQ/Og4piZYHrcR89B9nc/uzFRFTS/0Z9OdaS1lXf9U5ohxhx9ZU QjxOvXQ69W+Uu3ly1HINhpdGQZl75Pzbg7YwEW8OPm8wRS/H0B2zOJdWvMDVIp/pEXPt A4jA== X-Forwarded-Encrypted: i=1; AJvYcCXwC7DC9uHnmaoePCUp+SyZ6WlECi0soY08egC2M2xlA5fTqwvjYTvXeItuagB0FtIlq+zGjA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyRI6BTQzwlpCoGXe4S6QnuXBEC5a+yr43srwoNLfhl3Vd0kPQa XFfy8vpq7J8WqQXaN3me4PuEEjnsoaM8D041I9SStHNWs3Vwhiwh67dHrQ== X-Gm-Gg: ASbGncuwIizNM5HmqbfKT8A03K/OI7hIMSBntAwF7d2cPFJFCIAHrOGRpRLPALyvliM jiAVJXUjwkMfvPQlHfS7bvOo2vwYAYGqOvF56LoSk+e0p5lZii7x4K0ektzOtbyZdfhU58KOnui ZWeCA2I1MJh6a50UVsNVU0UZolDmM95yKwDRgErpTPHJHlRG/X+PseqOap6mpCDKtH5jGajH9FA LpQtTuwI6Fb9LAM5S8V4SWBnuiWnvIgyfDbFnFdCcCklocD/bh3NCef7oMrLBUbj/trzkOtuG1t +XQ6+8zAmSDMbuJwpOpYkWmEb/cJU21yKS0fV7XiCtSqyKZBGDTKSguyeuBQG/Iubg== X-Google-Smtp-Source: AGHT+IGVNjBVl+0MxJosjIfED4vU1xUV4h7ERBvudWU+UhGCvcpE08+wVxuu/e3wRpIzre0DXaC/Ug== X-Received: by 2002:a05:600c:3106:b0:434:a802:43d with SMTP id 5b1f17b1804b1-43668b93817mr444294995e9.27.1736073933240; Sun, 05 Jan 2025 02:45:33 -0800 (PST) Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-436612899f0sm536205835e9.38.2025.01.05.02.45.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 02:45:32 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <87frlxczxg.fsf@HIDDEN> (Pip Cet's message of "Sun, 05 Jan 2025 10:35:12 +0000") References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <m25xmtwxt7.fsf@HIDDEN> <86sepx8sth.fsf@HIDDEN> <m2wmf9v9ho.fsf@HIDDEN> <87frlxczxg.fsf@HIDDEN> Date: Sun, 05 Jan 2025 11:45:31 +0100 Message-ID: <m2o70lv8s4.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: Eli Zaretskii <eliz@HIDDEN>, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Pip Cet <pipcet@HIDDEN> writes: > Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > >> If "these two" means xstrdup and my SAFE_NALLOCA change, then yes, kind >> of. It doesn't harm to do both, but it's not strictly necessary to do >> xstrdup if the SAFE_NALLOCA change is in. The other way round is not > > For argv, I agree, but make_environment_block uses xnmalloc and assumes > SDATA pointers in there will survive, which they don't, according to my > GDB log. Ah, okay. Then both xstrdup and SAFE_NALLOCA. Which I have here so I'm good. > It was very brave not to start out by making every xmalloc an ambiguous > root and fixing only those that we know to be safe :-) The SAFE_ stuff was only 1 out of 6542 things to get going. And I'm absolutely reckless anyway :-).
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 10:40:41 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 05:40:40 2025 Received: from localhost ([127.0.0.1]:60045 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUO3k-0002TS-Ft for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 05:40:40 -0500 Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]:59794) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUO3i-0002TC-7q for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 05:40:38 -0500 Received: by mail-wm1-x332.google.com with SMTP id 5b1f17b1804b1-436281c8a38so96361115e9.3 for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 02:40:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736073632; x=1736678432; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=M5X+ROHHV0GltSEw4jdmWkcu0jqHtzdZKAf10W4w03g=; b=Dtqi7ueUSerSdvZ/PFbgG6Vq6lnkxtZGxa7Opkj2ph07U7sXfOLr55j9AqrcBUhTRf 6WIOvfB+UPWX/Po9oIsSTQ6ONSJF03JsoyPvbAVBp2VzaHW+HqyCVF18HY8uvPADZ8lz 9ixPLExQ3AIc0FQqLU3r2PtldyOegNa1jkffTpo72H7BIkJAPE8FGkE9txVTxKEwIlP/ 5m7RfxrGLJL2EGoen4DAYxRe+CkgmzN/2ZRpkA1vjBBl2WI9I4no6fGeYBnEoE11Qxix dDbG2OF1eKHdy8GBvNo5KwJSLadk4uA8XN4yU6PyXGpGgPAcJ4d05lRVkfx4f06ufC2S Ib1Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736073632; x=1736678432; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=M5X+ROHHV0GltSEw4jdmWkcu0jqHtzdZKAf10W4w03g=; b=Jx/gLlCHmk3Oiv0RUJirxXugjPMbEgarnFhbVYFCG29cmXv6/DzEkRFSKzskNz8Q4B vt2jYyp7I0pBzRJcZMu0EeYpPkMh54aEO641+ShG2bbxJzT2GrKrn2R86G575pX+hPaX uKsJBxzIJuXR/OujdwlmrrfWco/Gx5Q7tbVHKq79jjpdDfn4626atwJ0QctepwW4HtCF WKVJ6OuZoGpyGrzG8NmMcXixgHF9jrjmcNofJqZoN9TSqdYUeNmT6/TBUh1V8UwybyGJ hmYdkE0TozDX30wVzkbGGCNNdEWFJnqNfcFjVXt7us8Bj1la3m4H5g8rDQKpZkvFLpHe C40w== X-Forwarded-Encrypted: i=1; AJvYcCVta5POEBN9L//XOQ7hYJuSULM5H92AfyajQb85ZqPOt7OqHMSZ96Qd62If6oNsUs7P1DeRfQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YydvtLrXtbxDCf1DHD7OWZ5lgLQL6GWrB80zDNqm/WgvpQQqVAA YKnPNOS1EvUvgJEFkT+iz0UtlNONrPtB8+MEiVj9tQ0YULO/YoK/GisWFg== X-Gm-Gg: ASbGncuRMMcpnRtSsP5hc5LYn5wY+gqB0Ydq6VNTBv7sPni5H1yQVXZZdynz4fuXZno m2Pdd1BHmOl+1oEUx7HDcnDW3TUCkdDVNpg0pVIUCDljZrGaLH5Q3j56J7NS1CyKzRz5FF7pF1P 0I1kpKrsQ6B7+n4UCdHkDW5efVonlQCDOpJW7QHIlwETs8lcYdDJVH23FmqLzWcvpj2PJVmTiCB VQsv0eDO3Rc5qB+KciPZCKmRqSW7ACA99HZeT+zrP9/sD2EFpcTJXY6OSqJc4Q8LjK5wzAe3cbE Bkuk2Da/FwiRIcUxU/acg/NhN6haeiSZ5t/97plPrgHMpDcASpfir0AR2nxAMVhCGQ== X-Google-Smtp-Source: AGHT+IF849XaBRgL0UmbkcmLJHra90SHM4Ir/ae0ZZOMYVhpW6ga1ywcQ6szmGf3KqZSwO07w2DTUw== X-Received: by 2002:a05:600c:3596:b0:434:9dfe:20e6 with SMTP id 5b1f17b1804b1-43668b5dfc0mr415785015e9.23.1736073631579; Sun, 05 Jan 2025 02:40:31 -0800 (PST) Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43656a0b361sm568674735e9.0.2025.01.05.02.40.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 02:40:31 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <86r05h8s9d.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 05 Jan 2025 12:33:18 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <865xmtaeh9.fsf@HIDDEN> <m21pxhwu4a.fsf@HIDDEN> <86r05h8s9d.fsf@HIDDEN> Date: Sun, 05 Jan 2025 11:40:29 +0100 Message-ID: <m2sepxv90i.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org >> Date: Sun, 05 Jan 2025 09:19:17 +0100 >>=20 >> I'd grep for SAFE_NALLOCA, and for each occurrence, see what is stored >> in the memory allocated. > > Is only SAFE_NALLOCA a potential problem? What about the other > members of the SAFE_*ALLOC* family? Haven't checked others yet. I have that on my todo list now. > >> If that is a reference to MPS-allocated memory >> (a pointer or Lisp_Object), it should be changed, because it then hides >> references from MPS in malloc'd memory. Or can hide, to be more precise, >> in the case it doesn't use alloca. > > Does using igc_xnmalloc_ambig have any significant adverse effect on > GC? Like makes it slower or forces it to scan more memory? Because > if we make SAFE_NALLOCA do this by default, there could be quite a lot > more such ambiguous roots by the time GC starts. More roots =3D more to scan for GC. > If this could impact performance or has some other adverse effects, > I think I'd prefer to have a new argument to SAFE_NALLOCA telling it > whether to call igc_xnmalloc_ambig, and we will then need to audit our > code to use that argument where what's stored in the memory it > allocates could be a Lisp object. This is more error-prone, but > performance does count, especially where it comes to GC. > >> I think the performance impact of that is negligible because this >> path is only executed when SAFE_ALLOCA does not use alloca. > > MAX_ALLOCA is only 16KB (and Paul Eggert says it's dangerous to make > it significantly larger), so I'm not sure your assumption about > negligible performance impact is necessarily correct. Works well for me so far.=20
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 10:35:27 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 05:35:27 2025 Received: from localhost ([127.0.0.1]:60031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUNyh-0002D5-HZ for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 05:35:27 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:52383) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tUNyf-0002Cp-GB for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 05:35:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736073318; x=1736332518; bh=pnM8fzWINOE2SzwkzRDccBeef8VO3w6Qo8XURkLpf58=; 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=SkExokzlWDKS2v09a/Ol9XY7q9t6NqL30RSSRVwKcHMjttU9D13u3xW9BqM0n61RK 2GdFKIu6RaAlyq97CQiRvdQKxdOkjoT6xPk/DqkixdPiBsXnH2NVvz3E1U+VQjR0gw jrl907yDl4ujFt0RStPJOH40+zQB8RSRvZLCr5bnEfBkwQZ5zao7QypnDtwywu14/S B/OQkWKjvoXzr/4pLR5i9AKVtLpNgNbxcEXqrhUT2FqePggWbyNAXUOT2/q8+q3a4M Zo1urzdsaO2h+xfiAN5RMMCGFppxHoJhI+7N7Wtgk7yBAZ5VwKkEMXHb81vqbVXBwR ruh+cm9wfVbTw== Date: Sun, 05 Jan 2025 10:35:12 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Message-ID: <87frlxczxg.fsf@HIDDEN> In-Reply-To: <m2wmf9v9ho.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <m25xmtwxt7.fsf@HIDDEN> <86sepx8sth.fsf@HIDDEN> <m2wmf9v9ho.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: c33249577f5a4463a47329e95a7eb4b704bae18c MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: Eli Zaretskii <eliz@HIDDEN>, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > If "these two" means xstrdup and my SAFE_NALLOCA change, then yes, kind > of. It doesn't harm to do both, but it's not strictly necessary to do > xstrdup if the SAFE_NALLOCA change is in. The other way round is not For argv, I agree, but make_environment_block uses xnmalloc and assumes SDATA pointers in there will survive, which they don't, according to my GDB log. It was very brave not to start out by making every xmalloc an ambiguous root and fixing only those that we know to be safe :-) Pip
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 10:33:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 05:33:34 2025 Received: from localhost ([127.0.0.1]:60019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUNwr-00023E-L2 for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 05:33:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35768) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUNwp-000230-Ou for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 05:33:32 -0500 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 <eliz@HIDDEN>) id 1tUNwh-0005zH-8B; Sun, 05 Jan 2025 05:33:25 -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=Kr8wbFHYG1V8Hi+QH5XGLDQJsU2kQWKHp1Dcjqk21t4=; b=U/iWSy7s79AaHhhazEdl BlYiVZAzzEIYImJIKjU30Aouv0vndcunA4n5KBkeebgVUvSeOy+ul2fBQ+XMPBmgjE3dVWZl4cCXn Ez2FM8P8NtCwd/2UFHzEFF9EW2H9+JiIiIXDH50V8JfIpv2uG4hNbdareJAmeD2HcfLZJ7r0vGyDo fNVqluyNcNRimjD3bwEdk3w08FuNZLPVlWXe5Okcf6E/dXv1VoG10Jg4WkArTdZk51OAywU3tOAe1 GjANbUsdWFoolCKRpwS7Obu2Do+mnp8iby4VoauzxmTdiJbD1K/5ukq4eWKoT6oZk57aHaz2t+NH8 liAxBA0piqKqOA==; Date: Sun, 05 Jan 2025 12:33:18 +0200 Message-Id: <86r05h8s9d.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m21pxhwu4a.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sun, 05 Jan 2025 09:19:17 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <865xmtaeh9.fsf@HIDDEN> <m21pxhwu4a.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org > Date: Sun, 05 Jan 2025 09:19:17 +0100 > > I'd grep for SAFE_NALLOCA, and for each occurrence, see what is stored > in the memory allocated. Is only SAFE_NALLOCA a potential problem? What about the other members of the SAFE_*ALLOC* family? > If that is a reference to MPS-allocated memory > (a pointer or Lisp_Object), it should be changed, because it then hides > references from MPS in malloc'd memory. Or can hide, to be more precise, > in the case it doesn't use alloca. Does using igc_xnmalloc_ambig have any significant adverse effect on GC? Like makes it slower or forces it to scan more memory? Because if we make SAFE_NALLOCA do this by default, there could be quite a lot more such ambiguous roots by the time GC starts. If this could impact performance or has some other adverse effects, I think I'd prefer to have a new argument to SAFE_NALLOCA telling it whether to call igc_xnmalloc_ambig, and we will then need to audit our code to use that argument where what's stored in the memory it allocates could be a Lisp object. This is more error-prone, but performance does count, especially where it comes to GC. > I think the performance impact of that is negligible because this > path is only executed when SAFE_ALLOCA does not use alloca. MAX_ALLOCA is only 16KB (and Paul Eggert says it's dangerous to make it significantly larger), so I'm not sure your assumption about negligible performance impact is necessarily correct.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 10:30:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 05:30:23 2025 Received: from localhost ([127.0.0.1]:60014 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUNtm-0001x7-R3 for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 05:30:23 -0500 Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]:42158) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUNtk-0001vc-GV for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 05:30:21 -0500 Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-43635796b48so81241895e9.0 for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 02:30:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736073014; x=1736677814; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=AqDSLmw14RsdUHIzjfxoEXHRJWRxki/wk3TB3dg/Qkw=; b=nANNBEfEXrxUxMGbLp6GTfZUm6Jyfa5JP2I/CIigKO8HDWEBkeMzlyTEBV+DaIKk0O ErHhwiDgpjNTfLtvXSuVri0Vswyz0Igt7/a4zS7pGpEgmK2SdKbMY/ZIcrJ8JyPtrMYK UElEB8mjsaPYSbovOh0j+EFu3634v/9jSFQ0Ht+hJerJ4OVKoYNo+hXBZ9hlGTr2SCWZ AlcBBOhUL/CDqzdn8cXc5Zlqx734cB9xvyc1DZt5IjioL+mDxgbVVVGC5kzT6H3JQVw9 5TuX+X6OcYX1g/GD3v3vteobezFg8PDUVE/BvHpvxyR0KYU+aKo4R8ctXfMCrz8GAr/1 roMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736073014; x=1736677814; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=AqDSLmw14RsdUHIzjfxoEXHRJWRxki/wk3TB3dg/Qkw=; b=OJesZII9RWSV8MoiK6YcKrKAEwSaa0X7yX5kD/Bd26/TVTzXXy743LwyamKYbaPiBx b4UidQ11Fl7Zm3GeKlsB68jtl6o6Wsm1X4g8hxJFxdBb/CTyhWMhAa7VDrKKzwsLaXwg Evjq30dCNUF29lUkQaAl+o+/LmB8BLAy2ZDqoCScwKybPonPEYdzjFJyPIcqHDsgmctl 4RGodn7t8xuZ1z8YHqNiTgwic1V+RtlTK+iDwCJbWuZxmkp6D963lr2uGBfGxFuqZ4v/ wBEDUJ1fqy9PMGFPWxeum79AqrhD0baXh9tsVv3oGh2uWAlmJPy4DLiUF8KU35nANmqf KJSw== X-Forwarded-Encrypted: i=1; AJvYcCXw2RBpuglgznE/p+ROWnjrdUEtUpfH6gT55hQB0KxhQ/J7LT0ZvTDatF3n4k8I8m8LylXehQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzWNYvYuCwhziaMh6GkvbzWHT6R8mwqzmddpWV7dFGvOMqwU5NB XGWYF18bYQ3ZaGQt4DZJYtMZbrWlmuMnr9nIZAT/YbAFFyO4GJwgVyWRXw== X-Gm-Gg: ASbGncsfC0ft33u+Ix3eyQ3Tcx/2pT19fWtPMicTK896STD+4RY/g8kHATvy+rbgA7Y TsZWzPEzRch+XayYlkr1bamnsUGNfDX0AcXA1iPhw6RDw2eMOFN9P/KaAc8akPN5sQ4vyclDiXy Y9DFAaRHaVNmpR5EPsnNJzrk/9P3iXLP08Iv7o+eTiEmWnSkYDx2xSflwPHVHFdgoYr4rMiEsXo BiqS7EcqHP/GIVbNNemikgTX6Bgit9HAuR04Q4Zo4bZZukYzn3vI0jGwDQC6qIXC0L6pSL96yhM J/aBd2Khx/+A/2fXvdDuOskqMdXZ22Y3+UkhgLOKpv7wxwW5QR9AvbhklIZvL51xgg== X-Google-Smtp-Source: AGHT+IGyZ59wARm57vjN3PUi1XnfSGf+5+dhVflgrtgo3V8r7klNbmbtNHbpEqLxOfmQVI4VvZFtgQ== X-Received: by 2002:a05:600c:5d2:b0:436:747d:55c9 with SMTP id 5b1f17b1804b1-436747d5775mr389807755e9.5.1736073013765; Sun, 05 Jan 2025 02:30:13 -0800 (PST) Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43656af6c4esm569731415e9.4.2025.01.05.02.30.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 02:30:13 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <86sepx8sth.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 05 Jan 2025 12:21:14 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <m25xmtwxt7.fsf@HIDDEN> <86sepx8sth.fsf@HIDDEN> Date: Sun, 05 Jan 2025 11:30:11 +0100 Message-ID: <m2wmf9v9ho.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> Cc: 75322 <at> debbugs.gnu.org >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Date: Sun, 05 Jan 2025 07:59:32 +0100 >>=20 >> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: >>=20 >> > Just want to add that all SAFE_NALLOC uses should be checked in >> > scratch/igc. For example, set_overlays_multibyte uses it to store >> > itree_node *, and itree_node is in MPS. >> > >> > I think I'll just make it allocate a root in my Emacs. That's the least >> > work. >>=20 >> Please find attached what I'm using now in my Emacs, in addition to your >> xstrdup commit. > > These two are alternatives, right? IOW, we should use one or the > other in each specific case, is that correct? If you mean the two patches I sent with "these two", then no. I prefer using SAFE_ALLOCA_LISP because that introduces an exact root. If "these two" means xstrdup and my SAFE_NALLOCA change, then yes, kind of. It doesn't harm to do both, but it's not strictly necessary to do xstrdup if the SAFE_NALLOCA change is in. The other way round is not true, i.e. having the xstrdup change fixes only 1 case.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 10:21:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 05:21:26 2025 Received: from localhost ([127.0.0.1]:59992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUNl8-0001Rm-1v for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 05:21:26 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45708) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUNl5-0001RV-8m for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 05:21:24 -0500 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 <eliz@HIDDEN>) id 1tUNkz-0002RT-Hi; Sun, 05 Jan 2025 05:21:17 -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=D7TxjScJT0tYZ91A+YcPwifHIHsCs7wjBMMJjFN9slc=; b=n202xm/JLkE0a4iNZBCT 8pAnAm4QlsLVt8zY5Y2hsVpvZYXesgjFCcZjeOzDVCJygLgHc915eJr2JqzGhiF2HhWi+wmWS0b7r xaJwLsBE3L0LuXC/Id28N1h0UO0+V7ipYMdxDuO+jlSGdBD/8z8Z3qI5q2UFX9Exia+QZoXbIAOWx 3EAIfev+c1+I+F7qGUSSXayEGeZmNzvfFkf9ldHh2+oAwrn3sgx0H08Q6xh34lXctnoxPXtnSVNxQ E7deS3rtvQUV4pSarAD33mbR4ffB6Sy/cf9VkMltzPhy8btjocWgfEQqNU6ecX6VyFFMkp6vRNHNv kSgS25baD+1HRg==; Date: Sun, 05 Jan 2025 12:21:14 +0200 Message-Id: <86sepx8sth.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m25xmtwxt7.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sun, 05 Jan 2025 07:59:32 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <m25xmtwxt7.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 75322 <at> debbugs.gnu.org > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Date: Sun, 05 Jan 2025 07:59:32 +0100 > > Gerd Möllmann <gerd.moellmann@HIDDEN> writes: > > > Just want to add that all SAFE_NALLOC uses should be checked in > > scratch/igc. For example, set_overlays_multibyte uses it to store > > itree_node *, and itree_node is in MPS. > > > > I think I'll just make it allocate a root in my Emacs. That's the least > > work. > > Please find attached what I'm using now in my Emacs, in addition to your > xstrdup commit. These two are alternatives, right? IOW, we should use one or the other in each specific case, is that correct?
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 09:47:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 04:47:19 2025 Received: from localhost ([127.0.0.1]:59914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUNE7-00088W-IY for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 04:47:19 -0500 Received: from mail-40134.protonmail.ch ([185.70.40.134]:63639) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tUNE5-00088H-Hg for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 04:47:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736070430; x=1736329630; bh=jrHcG/wcUxkQdGerUmpgiFSNW5QYBuSaEvukVhqpIBU=; 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=R4pXmKVebESIJkGB5aDflohBtZMxVG8hdHD+l5mTT+e73vS5BtwUtYDuzx5TSLKGi JGXe0K8QYL3A2zZ7ryA2/cMiqsvkGZqTXwkYJKbff6fTNIrWy18+IdopQxXliHd7UV 8IEb9DYdYFThRNQfO3xoS1ekXaphVu2Rw2lgQ1ifT8/AJgCYWZbdCUeI8PDpgm9qCt nS2KtBEG8FJUAKcgctp72NDirsR4kDTEPhfSqgyXL0S1v5WuY7KyUtN0Ojb5ls4Zpq bpT7z8xPp1eFHhS4Ak9HD9PHSefGHKTBvXia4iQxNGTiSxZZxwi9PFUCtk64yCollG A/keRqq7WgxhA== Date: Sun, 05 Jan 2025 09:47:06 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Message-ID: <87ttadd25l.fsf@HIDDEN> In-Reply-To: <86ttad8v37.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <877c7aha9n.fsf@HIDDEN> <86y0zqbgot.fsf@HIDDEN> <87ttaee5qp.fsf@HIDDEN> <86a5c6b9sb.fsf@HIDDEN> <87ikque0xp.fsf@HIDDEN> <864j2dacuz.fsf@HIDDEN> <877c79eipq.fsf@HIDDEN> <86ttad8v37.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 802987a871a13f48a1df15e6a437d5094c70fcf4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> >> >> > The below is indeed unsafe: >> >> >> > >> >> >> > char *p =3D SDATA (unmarked); >> >> >> > ... trigger GC here ... >> >> >> > puts (p); >> >> >> >> >> >> Right now, that's safe for MPS, but not for the old GC, correct? >> >> > >> >> > If GC moves string data, then it is not safe, period. Does MPS mov= e >> >> > string data? >> >> >> >> MPS does not move string data if there is a stack variable pointing t= o >> >> it. It does in other cases. This is why it's safe for MPS. The old >> >> GC, IIUC, is less forgiving. >> > >> > The conclusion is that the above is NOT safe, because in some cases >> > the data could move. Which was what I said from the get-go. >> >> The conclusion is incorrect. The code is safe if MPS is in use, and we >> rely on that. > > No, we do NOT, and should NOT, rely on that! We do, we should, and we will continue doing so. > Because you yourself say above that MPS will move the string data in > some cases. Not in this case! >> The idea behind MPS is that you write code as above, which is safe when >> MPS is in use, rather than attempting to avoid GC, which is fragile at >> best (see call_process) and impossible in multi-threaded systems. > > I don't suggest to avoid GC. I suggest that where GC _can_ happen, we > must reinitialize the pointer to string data after GC. That suggestion is incorrect. MPS GC can and does happen while we have SDATA pointers on the stack, and we rely on it to keep those valid. We need not reinitialize anything after MPS GC, and we can't do so because we don't know when and how we are interrupted for MPS GC. IOW, MPS treats SDATA point the same way it treats Lisp_Objects. That isn't the problem here. The problem is that like Lisp_Objects, SDATA pointers cannot be moved to xmalloc'd memory and retain their validity. As long as you think MPS requires us to avoid GC in this case (this is implied by "we must do this or that after GC"), your understanding of how scratch/igc uses MPS is fundamentally incorrect. Pip
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.
Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 09:32:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 04:32:23 2025
Received: from localhost ([127.0.0.1]:59871 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tUMzf-0007NQ-EK
for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 04:32:23 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:58422)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUMzc-0007N6-Qe
for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 04:32:22 -0500
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 <eliz@HIDDEN>)
id 1tUMzW-000505-L7; Sun, 05 Jan 2025 04:32:14 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=jVfjYHXm67BasJDRopj0TK9tpYHiM/VXhjsR2qgFKuY=; b=oirDfHi712VD
1u6qRscldyjlAFcIDtBIaKxG9gtDgJSbfnz4/gz1eOOIHgXhyNUnKexQwOekT6q77unzqVx+2Qc9E
7rc32iQUC5hH6vx+IhYagvy5ICQFnZhDj3lQ16nPtRWMO4jT0+vMlCSjf1XG2n/RbiLLk0Y6UG6Db
LlNmU2M9tquvP29gAXZ+y5qzaBJ0yIeRmAx+DPefvt6zY7greQ5zG8njn5S5DfH2z7fETfC2BjeTv
xsZWGi5NCw2XU8cOwcDgSBRAGjcTz8gz9Z8oByB8hO/WrcOLoYRKTY1Kp+L0ZqXs83IrX6u/ekEPO
TQsVPMeutW/AdZqMVIBHqg==;
Date: Sun, 05 Jan 2025 11:32:12 +0200
Message-Id: <86ttad8v37.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
In-Reply-To: <877c79eipq.fsf@HIDDEN> (message from Pip Cet on Sun, 05
Jan 2025 09:04:06 +0000)
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
References: <87jzbbke6u.fsf@HIDDEN> <87a5c6j0qn.fsf@HIDDEN>
<86jzbad735.fsf@HIDDEN> <877c7aha9n.fsf@HIDDEN>
<86y0zqbgot.fsf@HIDDEN> <87ttaee5qp.fsf@HIDDEN>
<86a5c6b9sb.fsf@HIDDEN> <87ikque0xp.fsf@HIDDEN>
<864j2dacuz.fsf@HIDDEN> <877c79eipq.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 75322
Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Date: Sun, 05 Jan 2025 09:04:06 +0000
> From: Pip Cet <pipcet@HIDDEN>
> Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org
>
> "Eli Zaretskii" <eliz@HIDDEN> writes:
> > we should be able to use without restrictions static variables whose
> > values are Lisp strings.
>
> Without staticpro? That makes no sense whatsoever to me. It's not true
> for either garbage collector. Do you expect MPS to scan the entire
> data/bss segment ambiguously?
That's not relevant to the issue at hand, which was about the
following snippet:
static Lisp_Object unmarked;
^^^^^^
unmarked = string;
... trigger GC here ...
puts (SDATA (unmarked);
That 'unmarked' is a static variable is not relevant, because the
issue is the pointer to the text data of 'string', which value we put
int 'unmarked'.
> >> Which might be in a register and not survive until GC is triggered.
> >
> > A Lisp_Object variable will survive. Its pointer will be updated if
> > needed to point to the new location of the data. Thus, using the
>
> MPS never changes the value of an automatic variable.
Exactly!
> > Lisp_Object variable is always safe, but the pointer to its data must
> > be updated after a potential GC.
> >
> >> >> > The below is indeed unsafe:
> >> >> >
> >> >> > char *p = SDATA (unmarked);
> >> >> > ... trigger GC here ...
> >> >> > puts (p);
> >> >>
> >> >> Right now, that's safe for MPS, but not for the old GC, correct?
> >> >
> >> > If GC moves string data, then it is not safe, period. Does MPS move
> >> > string data?
> >>
> >> MPS does not move string data if there is a stack variable pointing to
> >> it. It does in other cases. This is why it's safe for MPS. The old
> >> GC, IIUC, is less forgiving.
> >
> > The conclusion is that the above is NOT safe, because in some cases
> > the data could move. Which was what I said from the get-go.
>
> The conclusion is incorrect. The code is safe if MPS is in use, and we
> rely on that.
No, we do NOT, and should NOT, rely on that! Because you yourself say
above that MPS will move the string data in some cases.
> The idea behind MPS is that you write code as above, which is safe when
> MPS is in use, rather than attempting to avoid GC, which is fragile at
> best (see call_process) and impossible in multi-threaded systems.
I don't suggest to avoid GC. I suggest that where GC _can_ happen, we
must reinitialize the pointer to string data after GC.
Otherwise, what was all that discussion about what call_process does
with the strings in the args[] array? If GC cannot change the data
pointer to SDATA, then why should we care about GC in that function?
> You seem to fundamentally disagree with me about how MPS works. We need
> to resolve that difference one way or another before we can continue any
> GC-related discussions.
I have a much larger issue here: this discussion produces an enormous
number of long messages without actually leading anywhere. Maybe I'm
too stupid to discuss this, but I cannot keep it going like that, it
eats up all my free time (of which I don't have too much to be gin
with).
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 09:04:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 04:04:23 2025 Received: from localhost ([127.0.0.1]:59824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUMYY-0005ss-Ld for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 04:04:23 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:21983) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tUMYV-0005sb-Kd for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 04:04:21 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736067852; x=1736327052; bh=mNz3oG7ljXndl4qoS5pQuUwDPovF5sWWzU3Qzqh1Ymk=; 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=Mf18hImFfM7co7TOWtsR3q1BXiN8vx1sLYh4C0t02zqUlsxYbr1Q+YnSUEpJvbjEF n6CE5El9YMIlSc+tYCyytv2Za5BJMye4M3fLA2HQcc8A7/KweO29WbNY1bRWB77eMM qb4gRV6zDhkdOcMXbI83Q3wI2Cn68gtMH9LFgO3x39uLhWtNNWJEBgF+MVgkm1h6b4 7gWXpWm8LJnq589jdKGudbbDJM+ebu6zaQ3qK77zsI6Moh0S/AcrkwETMOdEGdYuYK XYiDI7LqDoqwyJD2ZzEA9xUAkfi5pcaz6FeIFUWwGt3EIWSzmDYAiuXT1a3C7cNUmc XWBK6Et58K50g== Date: Sun, 05 Jan 2025 09:04:06 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Message-ID: <877c79eipq.fsf@HIDDEN> In-Reply-To: <864j2dacuz.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <87a5c6j0qn.fsf@HIDDEN> <86jzbad735.fsf@HIDDEN> <877c7aha9n.fsf@HIDDEN> <86y0zqbgot.fsf@HIDDEN> <87ttaee5qp.fsf@HIDDEN> <86a5c6b9sb.fsf@HIDDEN> <87ikque0xp.fsf@HIDDEN> <864j2dacuz.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: a78cda21f82877d299e5c14a5023df3114712291 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: > we should be able to use without restrictions static variables whose > values are Lisp strings. Without staticpro? That makes no sense whatsoever to me. It's not true for either garbage collector. Do you expect MPS to scan the entire data/bss segment ambiguously? >> Which might be in a register and not survive until GC is triggered. > > A Lisp_Object variable will survive. Its pointer will be updated if > needed to point to the new location of the data. Thus, using the MPS never changes the value of an automatic variable. > Lisp_Object variable is always safe, but the pointer to its data must > be updated after a potential GC. > >> >> > The below is indeed unsafe: >> >> > >> >> > char *p =3D SDATA (unmarked); >> >> > ... trigger GC here ... >> >> > puts (p); >> >> >> >> Right now, that's safe for MPS, but not for the old GC, correct? >> > >> > If GC moves string data, then it is not safe, period. Does MPS move >> > string data? >> >> MPS does not move string data if there is a stack variable pointing to >> it. It does in other cases. This is why it's safe for MPS. The old >> GC, IIUC, is less forgiving. > > The conclusion is that the above is NOT safe, because in some cases > the data could move. Which was what I said from the get-go. The conclusion is incorrect. The code is safe if MPS is in use, and we rely on that. The idea behind MPS is that you write code as above, which is safe when MPS is in use, rather than attempting to avoid GC, which is fragile at best (see call_process) and impossible in multi-threaded systems. We have to avoid the old GC in the !HAVE_MPS build, but with the MPS collector, there is no need (and no way) to avoid GC here. You seem to fundamentally disagree with me about how MPS works. We need to resolve that difference one way or another before we can continue any GC-related discussions. Pip
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 08:23:13 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 03:23:13 2025 Received: from localhost ([127.0.0.1]:59752 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tULui-0003qi-UJ for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 03:23:13 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47720) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tULuh-0003qT-38 for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 03:23:11 -0500 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 <eliz@HIDDEN>) id 1tULua-0001d3-Vf; Sun, 05 Jan 2025 03:23:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=lVjtk4Shi3ge2BQzj7BtU4bAIJNSt47SXrXcUTDMkXQ=; b=foy510bYUoYt c7Uxbm3Gft00Y70Kr8AQ7kLaeBCgscs8pDaiGJ9eX7nuWwTNk7DSOzsDXpagMi3AQl/V8+NsSAqK8 hbuuotmizlcXrgKTGErAIOejQiPivam8R/weexWm4kpovxKp+bpfjP8+0qCjVK/MToxPqOEuIOT8c KTYJxRp+uDovaBFGdGPX6MM4cx+VBvgjKgLoX9eUNhvN3iICfBECcamT+WNs1y4AnOaCOF0uY3MrO fJ/8T/OXyxPsn1d4riuWo16H35gaWbKS0aZV9tRs4twbvXxK/5DKJ66n8+VwqTxaFuqox5OUfazZW Duu45DuEvtp0EvAmlq1eng==; Date: Sun, 05 Jan 2025 10:23:00 +0200 Message-Id: <864j2dacuz.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87ikque0xp.fsf@HIDDEN> (message from Pip Cet on Sat, 04 Jan 2025 21:15:50 +0000) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> <87a5c6j0qn.fsf@HIDDEN> <86jzbad735.fsf@HIDDEN> <877c7aha9n.fsf@HIDDEN> <86y0zqbgot.fsf@HIDDEN> <87ttaee5qp.fsf@HIDDEN> <86a5c6b9sb.fsf@HIDDEN> <87ikque0xp.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 04 Jan 2025 21:15:50 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > >> > The safe thing is to re-initialize the pointer from the string > >> > whenever we think GC could happen, and otherwise make sure GC cannot > >> > happen. > >> > >> For the old GC, yes. For the new GC, the safe thing would be to ensure > >> MPS has removed all memory barriers, take the arena lock, then call the > >> syscall and return. Or use xstrdup. > > > > If this is indeed so (and I don't think it is), then we need to > > Which part do you think is wrong? All of what you describe. We should be able to use without restrictions local variables whose values are Lisp strings, and we should be able to use without restrictions static variables whose values are Lisp strings. To use the 'char *' pointer to a Lisp string's data we should make sure GC cannot happen between the time we extract the pointer using SDATA or SSDATA and the time we end the use of the pointer. If you think anything in the above is not correct with MPS, please tell. Please only respond with real practical problems, to keep this discussion concrete and on-topic. > > discuss it very thoroughly, because it basically means we cannot do > > anything with Lisp strings in C. For example, the display iterator > > has a member that is a Lisp string, which is used when we produce > > glyphs for display from a string (such as a display property or an > > overlay before/after string) -- what you say here basically means that > > we cannot carry that string around, right? If not, how is that > > different? > > Of course we can use Lisp strings. As long as there's an automatic > variable pointing to the string data, it'll stay there. If there's a > static variable pointing to the string data, it might move, but then the > static variable will be updated. Then I don't understand why you seem to be saying that our usual use patterns of Lisp strings and their textual data is unsafe and needs to be amended by using xstrdup etc. We do it already as described above. > >> >> 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 = string; > >> >> ... trigger GC here ... > >> >> puts (SDATA (unmarked); > >> >> > >> >> the most likely outcome (thanks to Gerd for the hint) is that > >> >> nonsensical data is printed > >> > > >> > Are you sure? > >> > >> With the static keyword, yes. (Assuming we don't staticpro the static > >> variable, of course). > > > > What does static have to do with this? > > What matters is whether the value is visible to the garbage collector > (in which case it remains a valid pointer) or isn't (in which case the > memory it points to is used for something else). > > Automatic variables, residing on the stack or residing in a register > (which is then spilled to the stack) protect the memory they point to. > Static variables don't unless we tell GC about them. > > > What matters is the value, not the storage. > > I have no idea what you mean by that. The value of the variable is a > tagged pointer. It won't change during GC, because GC never alters > automatic variables. The question is whether this pointer still points > to the right data area after GC. The pointer taken before GC might not point to the string's data after GC. Which is why, if we know GC could happen between two points in a program's code, we cannot use the same 'char *' pointer there; instead, we must recompute the pointer (by using SDATA) after the possible GC. > > The value comes from 'string', a different variable. It > > Which might be in a register and not survive until GC is triggered. A Lisp_Object variable will survive. Its pointer will be updated if needed to point to the new location of the data. Thus, using the Lisp_Object variable is always safe, but the pointer to its data must be updated after a potential GC. > >> > The below is indeed unsafe: > >> > > >> > char *p = SDATA (unmarked); > >> > ... trigger GC here ... > >> > puts (p); > >> > >> Right now, that's safe for MPS, but not for the old GC, correct? > > > > If GC moves string data, then it is not safe, period. Does MPS move > > string data? > > MPS does not move string data if there is a stack variable pointing to > it. It does in other cases. This is why it's safe for MPS. The old > GC, IIUC, is less forgiving. The conclusion is that the above is NOT safe, because in some cases the data could move. Which was what I said from the get-go. > >> > Before we agree that this could be the reason, we'd need to find the > >> > places where GC could reuse the memory of a live string, while that > >> > string appears in some live data structure, and as long as no GC can > >> > happen between the time we put the SDATA pointers into the environment > >> > array and the time posix_spawn returns. > >> > >> Calling igc_collect () right before the spawn results in corrupt data: > > > > But the code doesn't call igc_collect, so how is this relevant? > > This is all that is relevant to establishing the current code is not > safe for the intended behavior of scratch/igc, which is to allow garbage > collection at this point, equivalent to setting a breakpoint there and > calling igc_collect(). Why would we allow GC at some point where the code clearly does NOT expect GC to happen? We are discussing whether some code in callproc.c needs to be changed or is okay as it is. If it is okay because GC cannot possibly happen while some code fragment is being executed, then forcefully injecting a call to GC there is pointless, because it changes the conditions under which this code normally runs. So please keep such arguments out of this discussion, they just muddy the waters and are not useful. > I honestly don't know whether hitting a memory barrier can result in > other data being moved by MPS right now. I'm assuming it can, and we > should not assume string data is protected from being moved unless we > root it explicitly. We should not assume anything, we should have a clear understanding what does and what doesn't move the data and the pointers. We cannot possibly analyze the code otherwise, or at least I cannot. To keep this discussion focused, let's please return to looking at some particular code in callproc.c where you think SAFE_ALLOCA is unsafe.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 08:19:30 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 03:19:30 2025 Received: from localhost ([127.0.0.1]:59707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tULr8-0003bS-02 for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 03:19:30 -0500 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:51513) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tULr4-0003b5-7f for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 03:19:28 -0500 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-436249df846so92735895e9.3 for <75322 <at> debbugs.gnu.org>; Sun, 05 Jan 2025 00:19:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736065159; x=1736669959; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=/q4veFksP449FDi3aRQrzWYmOr5GFArhMF2SmJOGKxg=; b=k0LW4EZAEpkiUsxPxAEtU1kWujQYX+h+3oM1kBIGzkCoa+3oUsaGMyKnpb/cZk/O/u VpZ4NPBqGfwUk4P0z4X119P6mxr0gvCrVfSBwzARnZekLkT0op4O/PPicnEiIdOtJOQg NnghYrUb8/dDIo6aP6DZ4P44sVE0VCuKtt3Ei1UxFFkUldOY0DHtBRo/SM76jvgxt4Sa t62Hk4ckeornu6SJuPZJ/2Y4Ws7yRoghsIwUoaPxG/dPUQtGfflxn87f5HahmjOiTtzH bp/Fpspg+PWBjKISvB6pFGncLdkGDjxurCla71WOY3rN+W+4CPBx/od6Cw28zB9GbsaP ha5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736065159; x=1736669959; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=/q4veFksP449FDi3aRQrzWYmOr5GFArhMF2SmJOGKxg=; b=A5Rx0T+Ficdf+EI9oZORq9N70uMzcSpfU3xF6RZy14JZzAZJnc23bmIqrhYMF2bszz XTFwzlXxC5Bfhu1arkzUP4T3wf9BmUSLPLJSUfvnlVJFgW5CJoDh4eZG+VFAKIsQ6d6j d5HqSX7U6bGKRcIIqfCX3njD5g0f3EOU10jbNFEkWUxWmGJ2c17ZmHwAoIqEhS6r30X8 rEoLRl0tOPyVASUmF1FuLRdK9GeuRA26/KIfhJfUek4SGhaX5fszFcSZJUCKIFnFg0aN CfPRaqtezPTojgOyTkGS9biMG5CR4bCS246+5WCtD/2RbA5Q5hsRHaFZ7q+LS1bq7y6Q 3OvA== X-Forwarded-Encrypted: i=1; AJvYcCVgvGW2csif77AK7+9s975OdpAhljKzD+ymfS8ELekVMOje1m6wiTNEyDQsvYyu+o+BVAzwfA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzAhDv9OsCo0b9cm1EaXK2jh/w8+tUeLGT1cvTPJrCdQTcRI/ie HOcNktQF7KOj5IWv1bTQU4LdqJYobeEhDAwaoCxUw/SFQ8N/uHZnIz23gg== X-Gm-Gg: ASbGncsRE7HYWx8G/Samc7vMwejPuprK+ZTNXvgQyznXaeG3k0FNGZEo81+yNHX+x0b LnZEaac0NjqXXl/mjBogFpnz8vnYNxTMijM+x1mndV+uypYqEWARbnLkIVszn8f1TCr9jbJwYxu xgOrEym6SmSLy+RHwHqX+nMa1C7FP2W2Pc1wzA/KjLeiSivKGlrTkauXQDrofemouzIhN0WmUsS 5/GAPTBsghUGRKxHwK7Tu7krMJAlR4lXsPlooNAzaRt0zDsHbLhVbd9ppcPxhNPPE5tYBfA1qc8 fO+OSm5SUcBqvflw5hkrrvd6hogaqQCoSfcGVLIo/ljQt5sf6nwHQbz1Oe6l9WQGxQ== X-Google-Smtp-Source: AGHT+IGCAwE5rTSJbHWfVWcflYyjPiKiV/jt+i770P9zBroa2xxlSK6LvjnxuHIRTQPyL7OSH0g3Hw== X-Received: by 2002:a05:600c:3554:b0:434:a923:9310 with SMTP id 5b1f17b1804b1-43668646103mr498058125e9.15.1736065159450; Sun, 05 Jan 2025 00:19:19 -0800 (PST) Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c833149sm44566126f8f.39.2025.01.05.00.19.17 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 05 Jan 2025 00:19:19 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <865xmtaeh9.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 05 Jan 2025 09:48:02 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> <865xmtaeh9.fsf@HIDDEN> Date: Sun, 05 Jan 2025 09:19:17 +0100 Message-ID: <m21pxhwu4a.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> Cc: 75322 <at> debbugs.gnu.org >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Date: Sun, 05 Jan 2025 07:32:46 +0100 >>=20 >> Just want to add that all SAFE_NALLOC uses should be checked in >> scratch/igc. For example, set_overlays_multibyte uses it to store >> itree_node *, and itree_node is in MPS. > > Can you tell more about what should be checked and how? I'm probably > missing some details of the igc build, because I cannot translate what > you say above into practical actions of auditing the code. > > Thanks. I'd grep for SAFE_NALLOCA, and for each occurrence, see what is stored in the memory allocated. If that is a reference to MPS-allocated memory (a pointer or Lisp_Object), it should be changed, because it then hides references from MPS in malloc'd memory. Or can hide, to be more precise, in the case it doesn't use alloca. Or alternatively, you could avoid having to do that, and make SAFE_NALLOCA xmalloc an ambiguous root. A patch for that is in the other mail I sent. I think the performance impact of that is negligible because this path is only executed when SAFE_ALLOCA does not use alloca.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 07:48:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 02:48:15 2025 Received: from localhost ([127.0.0.1]:59634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tULMt-00024u-GN for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 02:48:15 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34462) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tULMr-00024h-I9 for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 02:48:14 -0500 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 <eliz@HIDDEN>) id 1tULMk-0008Fz-Ka; Sun, 05 Jan 2025 02:48:07 -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=vwuF1jorKS0/CDhxHp7676VqLsQHDxX2nCw2WJj6vao=; b=kKg2avYNCJUVkzmj78/u a86rR4aLAgZAmSgaYVk/LC3ttwDyKcU3hGFINAnd41OYvyX3C4nN45u1QklgHxZL8pZFmevKlETva tWFCciSiKSgheH5qg948zwE0xHI5doJMqqzb2WsUZm4eIFdD97pSRyDqaeVua6BIbn8X43ZtYVzjs LB2ufaqDMGUYUuSnNK9wUCSIxStJxS7pAqEmI8osirJyvSRwIiSOq64JrfmGWGI6rCh9SiQQqxTvi H4wAHgpCtbXcJ5s1ymm9+Pw3nqa06b4eCkNlBQapvPblP3fDLKDAgaKnC5qtnw+aMf4TSG1mim7EQ 4kNNYWYR0FN7zA==; Date: Sun, 05 Jan 2025 09:48:02 +0200 Message-Id: <865xmtaeh9.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m234hxwz1t.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sun, 05 Jan 2025 07:32:46 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 75322 <at> debbugs.gnu.org > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Date: Sun, 05 Jan 2025 07:32:46 +0100 > > Just want to add that all SAFE_NALLOC uses should be checked in > scratch/igc. For example, set_overlays_multibyte uses it to store > itree_node *, and itree_node is in MPS. Can you tell more about what should be checked and how? I'm probably missing some details of the igc build, because I cannot translate what you say above into practical actions of auditing the code. Thanks.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.
Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 06:59:45 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 01:59:45 2025
Received: from localhost ([127.0.0.1]:59313 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tUKbw-0007pG-FF
for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 01:59:45 -0500
Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:53249)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>)
id 1tUKbt-0007ox-L5
for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 01:59:42 -0500
Received: by mail-wm1-x336.google.com with SMTP id
5b1f17b1804b1-43624b2d453so138565055e9.2
for <75322 <at> debbugs.gnu.org>; Sat, 04 Jan 2025 22:59:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1736060375; x=1736665175; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=hT8mqltraMpwkdoOd/pysNbmH/TbTst/Qf31xX/EEJU=;
b=M9tRAERN7IRZgC544SB/SppK0o5wwil1r+dZZbkSvNN30WMkn7oUEFtquZ3EOOgArU
caADX6LEdA5k9tXuPxtu8VdcdCrSMROJazcp3YC7JVHx0YcIp4vnbWsnzZH7Zmlr/H2Z
WC3kY3K4IWIhc3a4jtmzss63wJze6O3cAJz+qcrpK+y06mp3oBTwQmZAYiDt+1aVFf2+
h/SWhp86Vv4SwOd4uGoMfHYh9m2H7y9KqzOH6ADTwqBydInP4QwwrL447mqPvMOGeiid
lm3LsvzfEY8FxZO/ufCSv2qpxMRvBjQEfZpDq8m4/ImdOU5flMu3AVp3J7gp6ptyyemU
4J4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1736060375; x=1736665175;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=hT8mqltraMpwkdoOd/pysNbmH/TbTst/Qf31xX/EEJU=;
b=dZH7mdLi8hs1PnTbf7XXem2hjAo7Q+XM3RsksE7iLenSXOKzHp2Twtzd2HQ2UMtiNM
UV4u22IwYAQ6/+SzqxkJ3L9PdvnkKZYv/iXJ4jAGPvkHjpsF1iECVeIdgEtb6NUhIvtw
r9Frh/fvw3wHL6KfQ+wMUTPcIq9+0iovBnDKsfuYTKYSFolw4xFFt2DSwpap9+9lUWdw
Gfieyg0tJT6PGzY6alCxzylgBkOM520VBwSGqwSNsnEJEgeXzHvHrYp7+L7CYNSmbQ3l
i2zXaVG9vEBJg4BISOVhssAD4Sm3JCpi80r0Hkqm52kjPW9r3C2H1udpg8WEyTVEoN25
Mbzg==
X-Gm-Message-State: AOJu0YwrUqKivvYd6Om9NtYdXY5jt6polztcSZu0qQfGWW0MVDOozJXl
rSeYrKtSbt2nsrj7YfgUMkgAXnHA9jnra6OZWJGrrQInHPHpHR3bdmemaA==
X-Gm-Gg: ASbGncsOdh4hZsNKTJXXNiFUAo4LvrdgQ3s3wH2Cave7vWm8EoiftCXjanOgbsb8LcA
wth7j++gb2NB6O4V+JXfJCwZxZR3bCrT+BzKXI5Dbq6OJjOkhZJ8H51+8k9bpDgPiClqhhR+whr
NEFauThqL8qLUB/l3eQLBNFazDBmREoOtlWaKGre9OjIJXPG2qVgEVNwJR/+aBIpMaA5+vY7wlQ
sKeI9pIWbesQphTo1ct4cuMPGcw7+ZYxqKK3WKmwCjxBZAchN+g/KFTOYyxcmU424OLNGW1j533
uoUa6YUXYE54Zu4IQXTOCphm5w/+rC2/F7UDmfcgSeBYX0GZ3j7DN4w+1fhatzdGTw==
X-Google-Smtp-Source: AGHT+IHiyJeQd4JV/anYq4WmIOzNBiwNEt7/TFKhyFkwJpON2lOQrC1xsTQsfce8CZPjqTutxIpArA==
X-Received: by 2002:a05:600c:474d:b0:436:18d0:aa6e with SMTP id
5b1f17b1804b1-4366835c14fmr463400005e9.5.1736060374698;
Sat, 04 Jan 2025 22:59:34 -0800 (PST)
Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de.
[2003:e0:b747:5000:78d7:74d9:8599:11e7])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-43656af6c4esm565719265e9.4.2025.01.04.22.59.33
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 04 Jan 2025 22:59:34 -0800 (PST)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
In-Reply-To: <m234hxwz1t.fsf@HIDDEN> ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?=
=?utf-8?Q?s?= message of "Sun, 05 Jan 2025 07:32:46 +0100")
References: <87jzbbke6u.fsf@HIDDEN> <m234hxwz1t.fsf@HIDDEN>
Date: Sun, 05 Jan 2025 07:59:32 +0100
Message-ID: <m25xmtwxt7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75322
Cc: 75322 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
> Just want to add that all SAFE_NALLOC uses should be checked in
> scratch/igc. For example, set_overlays_multibyte uses it to store
> itree_node *, and itree_node is in MPS.
>
> I think I'll just make it allocate a root in my Emacs. That's the least
> work.
Please find attached what I'm using now in my Emacs, in addition to your
xstrdup commit.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=0001-Don-t-use-SAFE_NALLOCA-for-Lisp_Objects.patch
From c364d3199a1b3b1a9ec0f9afe421110d46a77769 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd@HIDDEN>
Date: Sat, 4 Jan 2025 19:42:50 +0100
Subject: [PATCH 1/2] Don't use SAFE_NALLOCA for Lisp_Objects
* src/callproc.c (call_process, create_temp_file): Use SAFE_ALLOCA_LISP
instead of SAFE_NALLCA.
---
src/callproc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/callproc.c b/src/callproc.c
index 459ddbeb4f3..6f358f939de 100644
--- a/src/callproc.c
+++ b/src/callproc.c
@@ -423,7 +423,7 @@ call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd,
val = Qraw_text;
else
{
- SAFE_NALLOCA (args2, 1, nargs + 1);
+ SAFE_ALLOCA_LISP (args2, 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);
@@ -741,7 +741,7 @@ call_process (ptrdiff_t nargs, Lisp_Object *args, int filefd,
{
ptrdiff_t i;
- SAFE_NALLOCA (args2, 1, nargs + 1);
+ SAFE_ALLOCA_LISP (args2, nargs + 1);
args2[0] = Qcall_process;
for (i = 0; i < nargs; i++) args2[i + 1] = args[i];
coding_systems
@@ -1033,7 +1033,7 @@ create_temp_file (ptrdiff_t nargs, Lisp_Object *args,
Lisp_Object coding_systems;
Lisp_Object *args2;
USE_SAFE_ALLOCA;
- SAFE_NALLOCA (args2, 1, nargs + 1);
+ SAFE_ALLOCA_LISP (args2, nargs + 1);
args2[0] = Qcall_process_region;
memcpy (args2 + 1, args, nargs * sizeof *args);
coding_systems = Ffind_operation_coding_system (nargs + 1, args2);
--
2.47.1
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=0002-Make-SAFE_NALLOCA-allocate-an-ambiguous-root.patch
From 5b0a46390dfb5407cb7585bcbb1b7491d81885ea Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd@HIDDEN>
Date: Sun, 5 Jan 2025 07:45:51 +0100
Subject: [PATCH 2/2] Make SAFE_NALLOCA allocate an ambiguous root
* src/igc.c (igc_xnmalloc_ambig): New function.
* src/igc.h: Declare it.
* src/lisp.h (SAFE_NALLOCA): Use it.
---
src/igc.c | 6 ++++++
src/igc.h | 1 +
src/lisp.h | 19 +++++++++++++++++++
3 files changed, 26 insertions(+)
diff --git a/src/igc.c b/src/igc.c
index 54131d5fcf3..10f74c66d8f 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -3144,6 +3144,12 @@ igc_xzalloc_ambig (size_t size)
return p;
}
+void *
+igc_xnmalloc_ambig (ptrdiff_t nitems, ptrdiff_t item_size)
+{
+ return igc_xzalloc_ambig (nitems * item_size);
+}
+
void *
igc_realloc_ambig (void *block, size_t size)
{
diff --git a/src/igc.h b/src/igc.h
index 2a9bcda58b2..656a384aacf 100644
--- a/src/igc.h
+++ b/src/igc.h
@@ -86,6 +86,7 @@ #define EMACS_IGC_H
struct Lisp_Buffer_Local_Value *igc_alloc_blv (void);
void *igc_alloc_handler (void);
void *igc_xzalloc_ambig (size_t size);
+void *igc_xnmalloc_ambig (ptrdiff_t nitems, ptrdiff_t item_size);
void *igc_realloc_ambig (void *block, size_t size);
void igc_xfree (void *p);
Lisp_Object *igc_xalloc_lisp_objs_exact (size_t n);
diff --git a/src/lisp.h b/src/lisp.h
index 67b574a67b7..32e2886561c 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -6109,6 +6109,23 @@ #define SAFE_ALLOCA(size) ((size) <= sa_avail \
NITEMS items, each of the same type as *BUF. MULTIPLIER must
positive. The code is tuned for MULTIPLIER being a constant. */
+# ifdef HAVE_MPS
+void *igc_xnmalloc_ambig (ptrdiff_t nitems, ptrdiff_t item_size);
+void igc_xfree (void *p);
+
+#define SAFE_NALLOCA(buf, multiplier, nitems) \
+ do { \
+ if ((nitems) <= sa_avail / sizeof *(buf) / (multiplier)) \
+ (buf) = AVAIL_ALLOCA (sizeof *(buf) * (multiplier) * (nitems)); \
+ else \
+ { \
+ (buf) = igc_xnmalloc_ambig (nitems, sizeof *(buf) * (multiplier)); \
+ record_unwind_protect_ptr (igc_xfree, buf); \
+ } \
+ } while (false)
+
+#else
+
#define SAFE_NALLOCA(buf, multiplier, nitems) \
do { \
if ((nitems) <= sa_avail / sizeof *(buf) / (multiplier)) \
@@ -6120,6 +6137,8 @@ #define SAFE_NALLOCA(buf, multiplier, nitems) \
} \
} while (false)
+#endif
+
/* SAFE_ALLOCA_STRING allocates a C copy of a Lisp string. */
#define SAFE_ALLOCA_STRING(ptr, string) \
--
2.47.1
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 5 Jan 2025 06:32:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Jan 05 01:32:58 2025 Received: from localhost ([127.0.0.1]:59268 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUKC1-0006OP-Tn for submit <at> debbugs.gnu.org; Sun, 05 Jan 2025 01:32:58 -0500 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:51352) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tUKC0-0006O9-01 for 75322 <at> debbugs.gnu.org; Sun, 05 Jan 2025 01:32:56 -0500 Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-385e0e224cbso6676046f8f.2 for <75322 <at> debbugs.gnu.org>; Sat, 04 Jan 2025 22:32:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736058769; x=1736663569; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=jYLniSKT0t1guNUy+HFAFZ0BxAXYZuEOe7YwBWV8Pag=; b=TJQlLY4Ybz25q9iQpy6wG0ACRTfogvw9Jlaf3Rd06BhT/EgHbmMZal5gAOp4Ex1qvW 1gQjF7eWAfTRFPHMmSjhHf+H8fGu8Mh7uwimHmcyZ9J4BZPf/WWtrq3pg/6iZHtmOfdn wfkrtYM0bbgxE23W4bDO5MrjiAA8CIbndVKf2z/Gszz6AMbTuGFUWms7URx0GL7O3VAB U9QGLkJi6w1L5y0ujIA7ErT5D4alW5kv/jwPErTJ2Y6XkQiBprCbq1xRxR3Yi1P6CViV 57LNqDIL34O3Ru88hlTo2DNfb35arG9n6MUQ7Jt3jk/SMSGZK916AY4M+S6cQq/FK0y0 O2yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736058769; x=1736663569; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=jYLniSKT0t1guNUy+HFAFZ0BxAXYZuEOe7YwBWV8Pag=; b=Oe5m9DdkQduZxlIQLCvc07Ft35QopW0UOwTTjd1uH1kZBuebizkazuNGW9N5BtC0qR 6UTizTulV6agwsLGopnVYyU/U0s6nx9X2NxYV9X3uys3aCb1mbnDGvi1aAjqCRxYznqL nfLvo9lPEhMinnlZGgJZwwms+g0GmyQiZV6zb++N6EIBTDP7C7q42VMTMhUD+IPBMWEK I+ajRjUJcf1Pk2UCjaTyFYTYv0btGhnrTPNLQEctBWf/aWMoRLkbuB5uYr6gO+Aj7ZEO uilniyJ/ez1ebXzW7UzPDWf57ipi176S3n+EsM4YXI4sJvhFoYfX/wBVS9+UDH+rfnhM vMyw== X-Gm-Message-State: AOJu0YzonWNKHAZ4BOtGYfW3d4FhYj2ic9vjnQq2ay5ljZVppIOr1IPA vOiJuS6BVHvXLk6rjr3poq9kJ/gX0xEoRcNSNxSoqAggC7aCW2w42OnmPg== X-Gm-Gg: ASbGncsVRYGa7HIwuqXRAYNo45Cl3dKyuEWwMRephd72vOfds+l5UF5cnwhCrTByT3+ pMTfKIEKwoMGie6U8BZcn7MWCDHDm1A2pVGYbpJg1n8SJsYeXypyHPt1LCJObj3FZ//zORjhHCD 1kB3DMUaL8GadokRMDlzfXq1PGamqUyihV6no/N1MjdqCOpf7A3RPlZHXfuz7DGD5G/YVZ0y6CS k5Ll/gXngoUoQzIM+eB4QsKyWTW14O5Uvmxg7CVVIUGomHuJPxmQuFORFLycW2gbj952DxDA4h1 4mwGVirLr6N40rehPrP7z2ExKu1pA53Wx35qkJcvveV6cm9VFEtEhSch+dTHq97cWA== X-Google-Smtp-Source: AGHT+IEfj6BRamLfWZ/GWmsDDa374oTrOSDg6bfRGrhOQc9VI0I8gRrKxdj6Q1oPcrjgtT9DQzDwEw== X-Received: by 2002:a5d:5f4a:0:b0:385:f19f:5a8f with SMTP id ffacd0b85a97d-38a221f2d90mr40979180f8f.4.1736058768971; Sat, 04 Jan 2025 22:32:48 -0800 (PST) Received: from pro2 (p200300e0b747500078d774d9859911e7.dip0.t-ipconnect.de. [2003:e0:b747:5000:78d7:74d9:8599:11e7]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c847263sm44608701f8f.50.2025.01.04.22.32.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jan 2025 22:32:47 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <87jzbbke6u.fsf@HIDDEN> (Pip Cet's message of "Fri, 03 Jan 2025 17:20:40 +0000") References: <87jzbbke6u.fsf@HIDDEN> Date: Sun, 05 Jan 2025 07:32:46 +0100 Message-ID: <m234hxwz1t.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Just want to add that all SAFE_NALLOC uses should be checked in scratch/igc. For example, set_overlays_multibyte uses it to store itree_node *, and itree_node is in MPS. I think I'll just make it allocate a root in my Emacs. That's the least work.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 21:16:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 16:16:01 2025 Received: from localhost ([127.0.0.1]:57685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUBV2-0005PX-Vo for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 16:16:01 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:24041) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tUBV0-0005PJ-JY for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 16:15:59 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736025352; x=1736284552; bh=Gud4Ebo6z/eXhA2V9Mie+lc7zfeBlv3qTetynE/z61Q=; 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=L9Kny33RH6LLUGVjDnnvyBdCo7uPc6f43sEMsPynctjxZa6guqYp0CTemVT8zILMO HEiqqoOS50Iicx4Dwq5yfvIpoFhy9qfg45wEuZF1HWL6JkSaSRWnhF3pHHtd1fx7QL rYCiPmwxlWb7u6JFeJ5+wEpI4yPGJMjC43S5wJb+vk8W05iFKTVIYHozGWsddiwqDm oExYAAueVF4CxRGXChCzcwfnyc0vaNpnxYpfOSrBsXHTb6Ljqv0ZHYKcNg+XcgIZ/c ulvTyczXHS5LvmPO8iN4Uokg1yy9/3IY3CtyrVfk4YW7OX2lph8mf0thwI7+O3fdF3 zP37sh7AeNv6A== Date: Sat, 04 Jan 2025 21:15:50 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Message-ID: <87ikque0xp.fsf@HIDDEN> In-Reply-To: <86a5c6b9sb.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> <87a5c6j0qn.fsf@HIDDEN> <86jzbad735.fsf@HIDDEN> <877c7aha9n.fsf@HIDDEN> <86y0zqbgot.fsf@HIDDEN> <87ttaee5qp.fsf@HIDDEN> <86a5c6b9sb.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 50ed6a949c541824ee82318b242abf003af2afb6 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> > The safe thing is to re-initialize the pointer from the string >> > whenever we think GC could happen, and otherwise make sure GC cannot >> > happen. >> >> For the old GC, yes. For the new GC, the safe thing would be to ensure >> MPS has removed all memory barriers, take the arena lock, then call the >> syscall and return. Or use xstrdup. > > If this is indeed so (and I don't think it is), then we need to Which part do you think is wrong? > discuss it very thoroughly, because it basically means we cannot do > anything with Lisp strings in C. For example, the display iterator > has a member that is a Lisp string, which is used when we produce > glyphs for display from a string (such as a display property or an > overlay before/after string) -- what you say here basically means that > we cannot carry that string around, right? If not, how is that > different? Of course we can use Lisp strings. As long as there's an automatic variable pointing to the string data, it'll stay there. If there's a static variable pointing to the string data, it might move, but then the static variable will be updated. >> >> 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 barri= er. >> >> >> >> 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 >> > >> > Are you sure? >> >> With the static keyword, yes. (Assuming we don't staticpro the static >> variable, of course). > > What does static have to do with this? What matters is whether the value is visible to the garbage collector (in which case it remains a valid pointer) or isn't (in which case the memory it points to is used for something else). Automatic variables, residing on the stack or residing in a register (which is then spilled to the stack) protect the memory they point to. Static variables don't unless we tell GC about them. > What matters is the value, not the storage. I have no idea what you mean by that. The value of the variable is a tagged pointer. It won't change during GC, because GC never alters automatic variables. The question is whether this pointer still points to the right data area after GC. Unless there happens to be another ambiguous reference to the string data (which means MPS cannot move the string data, because it cannot alter ambiguous references), an unprotected static Lisp_Object will most likely point to invalid data after MPS GC runs. > The value comes from 'string', a different variable. It Which might be in a register and not survive until GC is triggered. Or it might be a global/static variable which is in an exact root, which means the data can be moved, 'string' will be updated, 'unmarked' won't. > points to string data, and it's that string data that is of interest > to us in the above snippet. >> > The below is indeed unsafe: >> > >> > char *p =3D SDATA (unmarked); >> > ... trigger GC here ... >> > puts (p); >> >> Right now, that's safe for MPS, but not for the old GC, correct? > > If GC moves string data, then it is not safe, period. Does MPS move > string data? MPS does not move string data if there is a stack variable pointing to it. It does in other cases. This is why it's safe for MPS. The old GC, IIUC, is less forgiving. >> >> > To clarify, I was trying to understand whether the error message >> >> > reported by Ihor in another thread could have happened because of G= C >> >> > in this are of the code. >> >> >> >> I currently think that Ihor's test case calls execve () with nonsensi= cal >> >> "environment" strings a lot, and once in a while they'll even be behi= nd >> >> the barrier which causes an EFAULT. >> > >> > Before we agree that this could be the reason, we'd need to find the >> > places where GC could reuse the memory of a live string, while that >> > string appears in some live data structure, and as long as no GC can >> > happen between the time we put the SDATA pointers into the environment >> > array and the time posix_spawn returns. >> >> Calling igc_collect () right before the spawn results in corrupt data: > > But the code doesn't call igc_collect, so how is this relevant? This is all that is relevant to establishing the current code is not safe for the intended behavior of scratch/igc, which is to allow garbage collection at this point, equivalent to setting a breakpoint there and calling igc_collect(). That we have a specific code path which ends up in MPS code is a bonus. I honestly don't know whether hitting a memory barrier can result in other data being moved by MPS right now. I'm assuming it can, and we should not assume string data is protected from being moved unless we root it explicitly. (Just answering the GC questions for now, sorry). Pip
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 20:32:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 15:32:24 2025 Received: from localhost ([127.0.0.1]:57574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tUAop-0003Ra-RZ for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 15:32:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34404) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tUAon-0003RM-Ga for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 15:32:22 -0500 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 <eliz@HIDDEN>) id 1tUAoi-0004X8-1O; Sat, 04 Jan 2025 15:32:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=DuiRCYQsARmL021cp51N9cc8YuKtHbOj2tCU1KOxqWY=; b=ZPTTFSM3pIfO 1IYkc+20uqJZ0FhiRJCwox7f+NIpZwi34Mmz54QJGzoBWUktCL09QlsByu2vXd6KZH46GjF51oAVJ ydPeknKnGwqndLgMyA0lPn9alrkNd/5UuzG5MCWWcvNAet1DiKnj9alHDn+ggtLifrltn2X9WwFAA 6WQfWZSnz4pcd2WOUllor4R9FSVbCPwAsc1aKj+OdYxFD1aUFlOPVoV6hIBtKT/KPKoDdQHfwv3DX Cm4WAxo3niMJF7PvEPdx3hcXkPgvE81tdDnaywUm5YvJsULY9YeK/62LFEkAKi8QxNipf014JIx1A l7zfV9hOKbi0DETr1LSetQ==; Date: Sat, 04 Jan 2025 22:31:48 +0200 Message-Id: <86a5c6b9sb.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87ttaee5qp.fsf@HIDDEN> (message from Pip Cet on Sat, 04 Jan 2025 19:32:01 +0000) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> <87a5c6j0qn.fsf@HIDDEN> <86jzbad735.fsf@HIDDEN> <877c7aha9n.fsf@HIDDEN> <86y0zqbgot.fsf@HIDDEN> <87ttaee5qp.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 04 Jan 2025 19:32:01 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org > > > ENCODE_FILE can indeed trigger GC in rare cases, but I see only one > > such call: > > > > path = ENCODE_FILE (path); > > > > We could simply move this to before the loop that sets up new_argv[]. > > Fixing the current code for this super-rare case would be good, but my > point was that we cannot prove the current code to be correct; it isn't, > technically speaking, even though it's battle-worn. I want to be pragmatic and solve practical problems in my life time. Proving that the code is correct I leave to the next generation. > >> >> 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. > > > > Sorry, I don't understand: why macros? Do we use something like that > > anywhere else in Emacs? > > How is it different from other easserts? emacs_spawn has > > eassert (input_blocked_p ()); How do you eassert something that should not happen during some code fragment? If you have something specific in mind, do show the code. > >> 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. > > > > First, the techniques that rely on separate segments are non-portable, > > so not all platforms will support them. More importantly, I'm afraid > > Absolutely, debug builds on the main platforms can, though. But then important code that is #ifdef SOME-PLATFORM cannot be handled like that, and we are back at square one, because users of "non-main platforms" still report bugs and we try to investigate and fix them, so we still need to be able to solve this when separate segments are not available. > > the amount of code where we currently don't expect GC is much more > > than you seem to imagine, so I don't think the above is practical. > > That's why I want to remove most non-GC assumptions first. I gave up > the last time I tried doing this, FWIW, for the reason you describe. > > > In any case, the starting point is to audit all the places where GC > > can happen, and that needs to be done anyway if we want to do it > > thoroughly and proactively (as opposed to only when someone reports a > > bug). > > I don't see how putting a few macros in while we're there could hurt :-) We neither saw any macros yet nor have any idea how many of them will be needed. So I don't know why you think it's just a few macros. We are still discussing a tiny static function and haven't arrived at an agreed and safe solution. Let's be a bit more practical here, okay? > > The safe thing is to re-initialize the pointer from the string > > whenever we think GC could happen, and otherwise make sure GC cannot > > happen. > > For the old GC, yes. For the new GC, the safe thing would be to ensure > MPS has removed all memory barriers, take the arena lock, then call the > syscall and return. Or use xstrdup. If this is indeed so (and I don't think it is), then we need to discuss it very thoroughly, because it basically means we cannot do anything with Lisp strings in C. For example, the display iterator has a member that is a Lisp string, which is used when we produce glyphs for display from a string (such as a display property or an overlay before/after string) -- what you say here basically means that we cannot carry that string around, right? If not, how is that different? > >> 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 = string; > >> ... trigger GC here ... > >> puts (SDATA (unmarked); > >> > >> the most likely outcome (thanks to Gerd for the hint) is that > >> nonsensical data is printed > > > > Are you sure? > > With the static keyword, yes. (Assuming we don't staticpro the static > variable, of course). What does static have to do with this? What matters is the value, not the storage. The value comes from 'string', a different variable. It points to string data, and it's that string data that is of interest to us in the above snippet. > > The below is indeed unsafe: > > > > char *p = SDATA (unmarked); > > ... trigger GC here ... > > puts (p); > > Right now, that's safe for MPS, but not for the old GC, correct? If GC moves string data, then it is not safe, period. Does MPS move string data? > >> > 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. > > > > Before we agree that this could be the reason, we'd need to find the > > places where GC could reuse the memory of a live string, while that > > string appears in some live data structure, and as long as no GC can > > happen between the time we put the SDATA pointers into the environment > > array and the time posix_spawn returns. > > Calling igc_collect () right before the spawn results in corrupt data: But the code doesn't call igc_collect, so how is this relevant? Please see how I described the situation in the paragraph above. > So the only mystery left is what causes GC to be called on current > scratch/igc after the environment block has been created; That's the _only_ mystery, and only if that in fact happens. Someone should explain how GC _can_ happen in that case on the igc branch. If you can, please do, and let's stop arguing about theoretical possibilities. > My current theory is that igc_on_grow_specpdl (called indirectly from > here: > > /* Do the unwind-protect now, even though the pid is not known, so > that no storage allocation is done in the critical section. > The actual PID will be filled in during the critical section. */ > record_unwind_protect (call_process_cleanup, Fcurrent_buffer ()); > > ) releases the arena, and MPS uses that apparent opportunity to call > ArenaPoll which might do GC things. Evidence, please.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.
Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 19:32:17 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 14:32:17 2025
Received: from localhost ([127.0.0.1]:57462 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tU9sd-0000hm-W6
for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 14:32:16 -0500
Received: from mail-10630.protonmail.ch ([79.135.106.30]:10541)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1tU9sb-0000hV-0X
for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 14:32:14 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1736019124; x=1736278324;
bh=/PhpZgtpf4yj/ZKz2T0Ke7L61JZ0Sf107iJYIuNG+ZI=;
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=QjHQ3IrSAH73PIhP2BbLSE1AnXXnqugsjvt49/ho2EzQI5W3siDrj9lYPB0jJB10Q
WDWwmN+vBkBkqnbQ5/z3VawwJZmc8WLA6TX8hUWhD3EfDNP584FNaQeQfTZ+CEsAXF
8hCPC3GH3N6ajlfFnWjssGbNriPN2oIWrc0Gn7HPysA9U/4YOU65nSqG4X57ZaAEo5
GC163tWZQaKjZ0dal/9ZTq9BTtQKFHbrTHtQY+V3+dWw3n746U0GeD1O0OM9PdTM+J
99SnmC5t35lBvA8TW8/o40Bm/LAwTNaT8yhXGG2rIoRguQ49et+xHuL/DzD0MB4Nss
Bp68y/r52B91Q==
Date: Sat, 04 Jan 2025 19:32:01 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
Message-ID: <87ttaee5qp.fsf@HIDDEN>
In-Reply-To: <86y0zqbgot.fsf@HIDDEN>
References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN>
<m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN>
<87a5c6j0qn.fsf@HIDDEN> <86jzbad735.fsf@HIDDEN>
<877c7aha9n.fsf@HIDDEN> <86y0zqbgot.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 19a505660cd17e8db9df073ee0cef67ce15876fe
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 75322
Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
"Eli Zaretskii" <eliz@HIDDEN> writes:
>> Date: Sat, 04 Jan 2025 15:26:01 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org
>>
>> "Eli Zaretskii" <eliz@HIDDEN> writes:
>>
>> > 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)?
>
> ENCODE_FILE can indeed trigger GC in rare cases, but I see only one
> such call:
>
> path =3D ENCODE_FILE (path);
>
> We could simply move this to before the loop that sets up new_argv[].
Fixing the current code for this super-rare case would be good, but my
point was that we cannot prove the current code to be correct; it isn't,
technically speaking, even though it's battle-worn.
>
>> 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.
>
> maybe_quit is not the problem, the problem AFAIU is that any encoding
> could have pre-write-conversion function written in Lisp.
Agreed, not the problem here.
>> >> 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.
>
> Sorry, I don't understand: why macros? Do we use something like that
> anywhere else in Emacs?
How is it different from other easserts? emacs_spawn has
eassert (input_blocked_p ());
static_assert (NIL_IS_ZERO) was intended to be a similarly proactive
macro marking the code making that assumption, but that didn't work out.
>> 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.
>
> First, the techniques that rely on separate segments are non-portable,
> so not all platforms will support them. More importantly, I'm afraid
Absolutely, debug builds on the main platforms can, though.
> the amount of code where we currently don't expect GC is much more
> than you seem to imagine, so I don't think the above is practical.
That's why I want to remove most non-GC assumptions first. I gave up
the last time I tried doing this, FWIW, for the reason you describe.
> In any case, the starting point is to audit all the places where GC
> can happen, and that needs to be done anyway if we want to do it
> thoroughly and proactively (as opposed to only when someone reports a
> bug).
I don't see how putting a few macros in while we're there could hurt :-)
> We can delay the decision what to do with these places to
> later, when we understand better the magnitude of the problem and its
> various aspects (in terms of several different effects that GC can
> have on various objects).
Agreed, I won't post a patch for now.
>> >> 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.
>
> I only meant that MPS is not very different from the old GC in this
> regard, that's all.
I think I understand now, thanks!
>> >> 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.
>
> The safe thing is to re-initialize the pointer from the string
> whenever we think GC could happen, and otherwise make sure GC cannot
> happen.
For the old GC, yes. For the new GC, the safe thing would be to ensure
MPS has removed all memory barriers, take the arena lock, then call the
syscall and return. Or use xstrdup.
>
>> 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
>
> Are you sure?
With the static keyword, yes. (Assuming we don't staticpro the static
variable, of course).
> The below is indeed unsafe:
>
> char *p =3D SDATA (unmarked);
> ... trigger GC here ...
> puts (p);
Right now, that's safe for MPS, but not for the old GC, correct?
>> > 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.
>
> Before we agree that this could be the reason, we'd need to find the
> places where GC could reuse the memory of a live string, while that
> string appears in some live data structure, and as long as no GC can
> happen between the time we put the SDATA pointers into the environment
> array and the time posix_spawn returns.
Calling igc_collect () right before the spawn results in corrupt data:
$ gdb --ar ./src/emacs -Q --batch --eval '(while t (with-temp-buffer
(shell-command "/usr/bin/env" t) (message "%S" (buffer-string))))'
(gdb) b posix_spawn
Breakpoint 1 at 0x535e0
(gdb) r
Starting program: ...
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Breakpoint 1.1, 0x00007ffff5c2b9c0 in posix_spawn () from /lib64/libc.so.6
(gdb) p igc_collect ()
$1 =3D void
(gdb) p env[1]
No symbol "env" in current context.
(gdb) up
#1 0x00005555558a805d in emacs_spawn (newpid=3D0x7ffffffeb148, std_in=3D4,=
std_out=3D6, std_err=3D6, argv=3D0x7ffffffeb0f0, envp=3D0x5555560bbae0,=20
cwd=3D0x7fffe3acb0c8 "/home/pip/emacs-forge/emacs", pty_name=3D0x0, pty=
_in=3Dfalse, pty_out=3Dfalse, oldset=3D0x7ffffffeb280) at callproc.c:1490
1490=09 vfork_error =3D posix_spawn (&pid, argv[0], &actions, &attribu=
tes,
(gdb) p envp[1]
$2 =3D 0x7fffe3a5ded0 "\bD\034\344\377\177"
(gdb) c
Continuing.
[Detaching after vfork from child process 5771]
"PWD=3D/home/pip/emacs-forge/emacs
SHLVL=3D0
_=3D/usr/bin/env
"
The old pointer pointed to an AMCZ pool (no barriers), but GC might have
reassigned the memory to an AMC pool (with barriers), which would cause
the EFAULT (and explain why it's so rare).
Hardcoding the assumption that string data is never behind a memory
barrier is a bad idea. We might want to change it back to an AMC pool
(I've done so in local debug builds so I could go back from string data
to the string metadata).
So the only mystery left is what causes GC to be called on current
scratch/igc after the environment block has been created; we know we
want to change the code so GC can be triggered from another thread, but
it's failing now, and there are no other threads yet!
My current theory is that igc_on_grow_specpdl (called indirectly from
here:
/* Do the unwind-protect now, even though the pid is not known, so
that no storage allocation is done in the critical section.
The actual PID will be filled in during the critical section. */
record_unwind_protect (call_process_cleanup, Fcurrent_buffer ());
) releases the arena, and MPS uses that apparent opportunity to call
ArenaPoll which might do GC things.
But, again, we want to make this code safe for GC at any time.
(We might be able to delay mps_arena_release until the next maybe_quit,
I guess)
Pip
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 19:25:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 14:25:05 2025 Received: from localhost ([127.0.0.1]:57432 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tU9lg-0000H2-UB for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 14:25:05 -0500 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:44461) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tU9le-0000F9-Ag for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 14:25:03 -0500 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-43618283d48so95466555e9.1 for <75322 <at> debbugs.gnu.org>; Sat, 04 Jan 2025 11:25:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736018701; x=1736623501; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=KJ2w4FvUzd2vzEqjeKV4eZGIezFTApQqAFYF6RUxqZY=; b=k5+4OZiOstTn/oRJZB/v69+abcEaF4NoyV8aFjUDpGnB+AOj9nKRSw1VkRM9M5Rabq +rPZA9sjON74T+3GDRfVH2hCl7dZYzKpFW2scGM9j2XbW2YA5hacwtWuRhl7gAMk3we5 FhfvoNrH4F3Q3bqv24Mg+B/CBYceV7aTFxM4oQGjYv8BXUQIy6NNxxU74RC4BUWWVDAD Q6gbtCUzuydsdJl/8D8diVaw1VrfbKlzli1GkWBZG9MWE4qmvBnjOMPfMfL3PmDwqriN +ojFFSI0aQfa7+yuxWSOjOFM/7MqoD+L6lQLU9Az7Sw7y3OzfSkh5KxFWe59O6a2OyEd dEYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736018701; x=1736623501; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=KJ2w4FvUzd2vzEqjeKV4eZGIezFTApQqAFYF6RUxqZY=; b=CRxf/K1R9o0l2cZD2A3xBXDTEPP1pphIuO8ZAZpLspv7YMlhwSIZ00YS18jUvGAdoT 4izxzYthFxTEkd3PFwKHcvB7tOQunqAgQnB3jle7qlloAYQeTNo44FCLNhL5ngrDASB8 857NsvnQYWRb0NxqEenYMzX6QyaWU1j+mHRxYTCmP6PkvFP8v1ub0WE8XtjX1sCs83m0 QsoMYlJ+h7Oz0ORgNTK6g4yhG1964V1+hngSVEQFsPV2Z5thzydtr4d/cvFLH/UXBM0y H9AJEUAfCFel4ZEo3iO5yVBV5gUvFpFjXw6vEF9RwTvjkyn2yyft5NTZmy+rIJpZFwIN tFEA== X-Forwarded-Encrypted: i=1; AJvYcCU6qPBR7hSi2zESMb2qzAjIj3jk4O1j3CJHZXF8l123rIV0Erf7HdnPKjl2rX8YV02MyXwoaQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yw36db0JsFvENxsV7UgywD0cZ0eukOQ8NAfd8T3edakJcqo/giH sPHAdX9mH2wAbYxsse+02bitgE/Vm3Haht0gsL5G898h4jmpEZiV71s5Ow== X-Gm-Gg: ASbGnct1JtTVYfJKg4Qxi+XjEsvgwLyJBCkK5Ht7PamAL0cBS4oky3Evr3gQ4bWBHh4 s2N2SmnIUkvRqVoztqe2mE6lo5qgJMz2V+mcUUPV9sO/i05yDqeqzy8/9mSoOskWjofSnFXr/2G Pr0cTcWgkHuQhmZH64DpBCNp4PjqIlJVof4aiHpwW1pBfhCI/jfF/NKfVBNbAqUM3qy4hsUqv94 /rd4j6DcOGAiQ0uDtNrHN/HeE1gYf5x5Mgi3vN5I3VrhlXkRFusu8HcZyxAB0BhAwn5D1Tr6BCZ IfnNU/c4quIaVct9kBK17Ft/9ukVWBjXOyWzlP0zoAJv6PxMiPsTbtLm7QghDEV1aA== X-Google-Smtp-Source: AGHT+IE8TmSmGWty/5ayrE10LTdqQNj+OM+fickZ4XxAeBAmqFFLEhFd+8OppUzmffG21sf+UfWC1Q== X-Received: by 2002:a05:600c:35d2:b0:434:a929:42bb with SMTP id 5b1f17b1804b1-436686464cemr486321995e9.18.1736018700445; Sat, 04 Jan 2025 11:25:00 -0800 (PST) Received: from pro2 (p200300e0b73c9f00c50ae305bf989514.dip0.t-ipconnect.de. [2003:e0:b73c:9f00:c50a:e305:bf98:9514]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c89e43dsm44498906f8f.70.2025.01.04.11.24.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jan 2025 11:25:00 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <86frlybdjv.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 04 Jan 2025 21:10:28 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> <87a5c6j0qn.fsf@HIDDEN> <86jzbad735.fsf@HIDDEN> <877c7aha9n.fsf@HIDDEN> <m2r05ik2yw.fsf@HIDDEN> <86ttaebfwq.fsf@HIDDEN> <m2jzbajulj.fsf@HIDDEN> <86frlybdjv.fsf@HIDDEN> Date: Sat, 04 Jan 2025 20:24:58 +0100 Message-ID: <m2jzbawfed.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org >> Date: Sat, 04 Jan 2025 19:35:04 +0100 >>=20 >> Eli Zaretskii <eliz@HIDDEN> writes: >>=20 >> > We are still arguing whether GC moves Lisp strings and what exactly >> > does that mean. We still don't understand well enough what, if >> > anything, are the problems with SAFE_ALLOCA and its ilk.=20 >>=20 >> I can't believe you say that. We talked about why xmalloc'd memory >> has to be a root if it contains references. SAFE_NALLOCA uses xnmalloc. >> Safe_ALLOCA_LISP does things differently. > > Sorry, I don't have a clear idea what that means. When can we use > SAFE_NALLOCA and friends? when can we or must we use SAFE_ALLOCA_LISP? > What are the considerations? etc. etc. I tried to explain that in igc.org, e.g. what roots are, or malloc in one section. That's the best I can come up with.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 19:10:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 14:10:40 2025 Received: from localhost ([127.0.0.1]:57406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tU9Xk-00085S-1S for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 14:10:40 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36700) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tU9Xh-00085E-8h for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 14:10:37 -0500 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 <eliz@HIDDEN>) id 1tU9Xb-0004h6-VJ; Sat, 04 Jan 2025 14:10:31 -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=1Z9FwLZNmDoc6ukFY/aOt+glTPVLPiAjlw+aZ7t6jag=; b=Mzd1Dnt01id6JSl9OC8L 1OkV05DtkWC0wAxAfn1qv9Ij1x0vUho6ElT7txsiMY+1sXWp7dtDMHFMYYjiPf3GYhA6eMpG9vU8B WKFwtrzxrCjiqGQikwnlcHmz4O8OtM4G/HT1waHlX+1bd7whrAgu1mFXON5D8BnrEpsgzK1SUeMqS UOIdnW3cV3omyudM1Pk4IkV82zW71+Uu1uqttyfDdq6cPkMN4uB5/OTAwFx69NRIpnYfV+Z22FkJJ D4tVxeZgQxu15256eb0Jm/ZXEit9qRnfWipjf/2VSCAnH8gH3Ghf8wb5A4cKX6a75tQObreMMrH9a htYek2irZkzUlQ==; Date: Sat, 04 Jan 2025 21:10:28 +0200 Message-Id: <86frlybdjv.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2jzbajulj.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sat, 04 Jan 2025 19:35:04 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> <87a5c6j0qn.fsf@HIDDEN> <86jzbad735.fsf@HIDDEN> <877c7aha9n.fsf@HIDDEN> <m2r05ik2yw.fsf@HIDDEN> <86ttaebfwq.fsf@HIDDEN> <m2jzbajulj.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org > Date: Sat, 04 Jan 2025 19:35:04 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > We are still arguing whether GC moves Lisp strings and what exactly > > does that mean. We still don't understand well enough what, if > > anything, are the problems with SAFE_ALLOCA and its ilk. > > I can't believe you say that. We talked about why xmalloc'd memory > has to be a root if it contains references. SAFE_NALLOCA uses xnmalloc. > Safe_ALLOCA_LISP does things differently. Sorry, I don't have a clear idea what that means. When can we use SAFE_NALLOCA and friends? when can we or must we use SAFE_ALLOCA_LISP? What are the considerations? etc. etc. I believe you that you have a clear idea, but we need all of us have a clear idea, and we should probably write that up somewhere once we do. > > We just established that ENCODE_FILE and ENCODE_SYSTEM can trigger GC, > > and didn't yet review the affected code. And there are many more > > places and calls to consider (e.g., do you know that redisplay could > > trigger GC when it calls character composition?). > > > > If we don't consider this stuff, if we just "do the xstrdup thing and > > forget about it", how can we continue cleaning up the igc branch and > > making its code more stable and reliable? It doesn't sound wise to > > me. > > I'll bow out of this discussion, sorry. This time for real :-). I'm sorry to hear that, because I think it's important to have you on board in this discussion.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 18:35:17 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 13:35:17 2025 Received: from localhost ([127.0.0.1]:57329 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tU8zV-0006VW-4F for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 13:35:17 -0500 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:54552) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tU8zM-0006QE-R8 for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 13:35:14 -0500 Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-4361815b96cso87195535e9.1 for <75322 <at> debbugs.gnu.org>; Sat, 04 Jan 2025 10:35:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736015707; x=1736620507; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=gMzBRWPq8OsdfqSUg/XE3GNWh3XhWiuB1ji8GGyD1DM=; b=N+ylbhuwyYK9i/lvvLuxuRD0DNfAGC/Cv+RGByku5jhGO+KKUW6gmQATxgivVntjcn 0RY6x1wrh8lSXIeJ/ukQ4itdGD9gS5wVxeNmYk2DK0oC8RHjBAH4j6QmqgOH3WfDJf6Z bJpCVoYMBh2j/WZz8cJ7ymSP9rH7qHXX4eeLw8SnT11zoBC5Voa7w4O49u+FHEpu6VVU VGYTabUOyHXNx1lsQ2saAMSZt+2q9DX75wG+lfT/DoTKUhptGe3kbdCjTY1hw/zvVPut 5w+7DbVshXtaojXz4+v64rFCEul7b6+XSp4u7oebc9K4ufhiaayJ0UR0Ldu1IpCFHcDS v1PQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736015707; x=1736620507; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=gMzBRWPq8OsdfqSUg/XE3GNWh3XhWiuB1ji8GGyD1DM=; b=Z/Xifv4d6ZiJlXs93sjeEmHHWGFUAm1vxbe5avgzNRw4/+Xdt078UI7LC9lTDeqF95 GG3iO4FNg94ITm0ZEtwaKw+QhYCnGwiFnVOvOACIQuJfDQycBeBeYsYVvzOyoaDYD3mq lEEc6uZoJnsvnf8p6JKCJRMFZ+kMTYkoDDL+X5sXRfTM8z77r35B+tl/nEjJqGKz2AeV a+PBmNihn/6+BOicT8ayWiyfQd0hbEAYvXOiOqiytXQJZRAH3gYIxBr3R33YexsimzNw IUETaH/sLlCkUhf7L8b0bMBJcUp/wq9ZxNxDudw6gxCbEWvzEo4l+fYawAZmJBBgb1nZ kWRg== X-Forwarded-Encrypted: i=1; AJvYcCVdb2eUdcHZHYSRoz0IGenf9iX9MEK1mhr/1iv6GJEwmPJd5F3FbZJl/8owKuukBm4w9Taqow==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwhDl2qcHAvMV/eelVzRZQr2X4guSxBQxtF+u2uveqUD1xYTjUb OR+vmOfrVCsyZS36UT4YpfloXgJwk1qjLcK2roBK51xTP0rImS3MSWvgww== X-Gm-Gg: ASbGnctDOPxLpH8kQZt21BYCnXc45KqMhjGuqOgeFovv6QgJZ16k+IOBs4pyfCxv/52 1wU62DZGC1HL3JWpM1oKUQTJw5RozmTSV0UviM4lSoUGMB3qmCQZcKW18l4+h0mZwsLs74SEB8q wU0mKBCOItqv5jEZ4UlVZi6Uyvgc1UQEbTvNU/iVKghr8jnPLobYCuYyeTpdP66NvnH+9i+D+OJ qeg7CsHYbY8waKzaYRlhrUmWx0CU4Y5G+Lj3Zvk2m3ERb3zxkFhEMaVT+rlHKFarsj2P9+tBXOU 8o51NRvKS9lXtkpuFXaF/AARK+TWZoAw3tn5O1mdYDiinvQMfbs9i5ROqZKmJQY5kA== X-Google-Smtp-Source: AGHT+IFmFjISTmI32pOIVkilFEzSgCT2+oqUtELqRxUyRqobAaajbWB3lt/cXpjcjbrz/3YjZyebug== X-Received: by 2002:a05:600c:3c98:b0:431:6083:cd38 with SMTP id 5b1f17b1804b1-4366854889amr424030725e9.6.1736015706420; Sat, 04 Jan 2025 10:35:06 -0800 (PST) Received: from pro2 (p200300e0b73c9f00c50ae305bf989514.dip0.t-ipconnect.de. [2003:e0:b73c:9f00:c50a:e305:bf98:9514]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c8acb17sm43124620f8f.97.2025.01.04.10.35.04 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jan 2025 10:35:06 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <86ttaebfwq.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 04 Jan 2025 20:19:33 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> <87a5c6j0qn.fsf@HIDDEN> <86jzbad735.fsf@HIDDEN> <877c7aha9n.fsf@HIDDEN> <m2r05ik2yw.fsf@HIDDEN> <86ttaebfwq.fsf@HIDDEN> Date: Sat, 04 Jan 2025 19:35:04 +0100 Message-ID: <m2jzbajulj.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Cc: Eli Zaretskii <eliz@HIDDEN>, 75322 <at> debbugs.gnu.org >> Date: Sat, 04 Jan 2025 16:34:15 +0100 >>=20 >> I'm entering a state of confusion again, as usual in this discussion. >> Can we _pretty please_ just do the xstrdup thing, and forget about it? > > We could do that, but what does this mean for our protocol of using > data from Lisp objects in libc and system calls? Does it mean we > cannot use SAFE_ALLOCA? Does it mean we must always xstrdup every > string and xmalloc every other object before calling some system API? > Are Lisp strings safe when GC can strike, or aren't they? What about > Lisp vectors? Etc. etc. > > We must figure out what are the safe and sound rules for doing this > with MPS, like we had with the old GC. Otherwise, we will be unable > to write correct and sound code, and we'll be unable to audit code > written by others. > > Right now, it doesn't seem to me like we have a clear idea of what's > permitted and what's unsafe.=20=20 I'd say I have a clear idea. > We are still arguing whether GC moves Lisp strings and what exactly > does that mean. We still don't understand well enough what, if > anything, are the problems with SAFE_ALLOCA and its ilk.=20 I can't believe you say that. We talked about why xmalloc'd memory has to be a root if it contains references. SAFE_NALLOCA uses xnmalloc. Safe_ALLOCA_LISP does things differently. > We just established that ENCODE_FILE and ENCODE_SYSTEM can trigger GC, > and didn't yet review the affected code. And there are many more > places and calls to consider (e.g., do you know that redisplay could > trigger GC when it calls character composition?). > > If we don't consider this stuff, if we just "do the xstrdup thing and > forget about it", how can we continue cleaning up the igc branch and > making its code more stable and reliable? It doesn't sound wise to > me. I'll bow out of this discussion, sorry. This time for real :-).
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 18:19:45 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 13:19:44 2025 Received: from localhost ([127.0.0.1]:57274 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tU8kS-0005gV-G7 for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 13:19:44 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49756) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tU8kQ-0005gH-GW for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 13:19:43 -0500 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 <eliz@HIDDEN>) id 1tU8kJ-0004oQ-RX; Sat, 04 Jan 2025 13:19:35 -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=LV1mQBE6XklXeddvt52jFqtlgQVMIMhMFV/+Scu3yuc=; b=reQ7gkUm8MM0xy+PlChH jvc5oxToQ/sJWSMCw5lo88R33W8btcFhtXAIpvH0cEhTnA3D3VKh1IEoCIcgRZm59TZ250MJ08lQK ngGJrhfow9PpEUcL1FrAk47OVe1KKF9W/aqd0zghW0LYZ1p2j95ASS4N2XjQEyPX8hSuJQQ/GTTBk Fn4SqNAVXImrscaEUPdbWY9lKk3byIIIEOC9Mrh/GWTXh7vQDb8H2pQLchbAG73uXJHkCq+9LpUro Fj9TZ+jN1ibjQLQ8JL5JJKjFeeui+tfzgN57osphYAoPUusBDxwnb8QxwtzDDuf7o+vSvfMeczwhI ZaqUGvpNv0TklQ==; Date: Sat, 04 Jan 2025 20:19:33 +0200 Message-Id: <86ttaebfwq.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2r05ik2yw.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sat, 04 Jan 2025 16:34:15 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> <87a5c6j0qn.fsf@HIDDEN> <86jzbad735.fsf@HIDDEN> <877c7aha9n.fsf@HIDDEN> <m2r05ik2yw.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, 75322 <at> debbugs.gnu.org > Date: Sat, 04 Jan 2025 16:34:15 +0100 > > I'm entering a state of confusion again, as usual in this discussion. > Can we _pretty please_ just do the xstrdup thing, and forget about it? We could do that, but what does this mean for our protocol of using data from Lisp objects in libc and system calls? Does it mean we cannot use SAFE_ALLOCA? Does it mean we must always xstrdup every string and xmalloc every other object before calling some system API? Are Lisp strings safe when GC can strike, or aren't they? What about Lisp vectors? Etc. etc. We must figure out what are the safe and sound rules for doing this with MPS, like we had with the old GC. Otherwise, we will be unable to write correct and sound code, and we'll be unable to audit code written by others. Right now, it doesn't seem to me like we have a clear idea of what's permitted and what's unsafe. We are still arguing whether GC moves Lisp strings and what exactly does that mean. We still don't understand well enough what, if anything, are the problems with SAFE_ALLOCA and its ilk. We just established that ENCODE_FILE and ENCODE_SYSTEM can trigger GC, and didn't yet review the affected code. And there are many more places and calls to consider (e.g., do you know that redisplay could trigger GC when it calls character composition?). If we don't consider this stuff, if we just "do the xstrdup thing and forget about it", how can we continue cleaning up the igc branch and making its code more stable and reliable? It doesn't sound wise to me.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 18:03:26 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 13:03:26 2025 Received: from localhost ([127.0.0.1]:57222 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tU8Uf-0004zu-AF for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 13:03:25 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38156) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tU8Uc-0004ze-AO for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 13:03:23 -0500 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 <eliz@HIDDEN>) id 1tU8UW-0005B2-NJ; Sat, 04 Jan 2025 13:03:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=lcPBe0uDI1zMMDREtvxafqOmBRSeFgCBG1PCul83AKk=; b=escBBF7DzipX lBuPXiVK9+5GENweizU+Gh2Djw/C34n0wx0PmrH7Pz0jDuHs5Xy6CrSVCwyE6xkaUZ/jgW4+9ZwsO X5rp0kfWJIouNwVA8oCGX2vtqs+J63RAwkXiErSgaYT4cO5U23g4iMs3JSVWaxyAvvXhzmpmFwg5o 7X1d2CGBfSScXJp4hfo1Uf8xe4CGBg8jAVzBOiLz+ZuGm93R/ZEx3GQwtnAoT3onDIHIxiCJqTq3G UGMd2hAJ+tKVPL9S/Q5FYe51Q7CWa57UkMoylSvwBK+PwOLuQ3GCOAJV+XubHGOUZ5Or3CiiT8paI llyqK9OH+N04NmP3vejK6w==; Date: Sat, 04 Jan 2025 20:02:42 +0200 Message-Id: <86y0zqbgot.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <877c7aha9n.fsf@HIDDEN> (message from Pip Cet on Sat, 04 Jan 2025 15:26:01 +0000) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> <87a5c6j0qn.fsf@HIDDEN> <86jzbad735.fsf@HIDDEN> <877c7aha9n.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 04 Jan 2025 15:26:01 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org > > "Eli Zaretskii" <eliz@HIDDEN> writes: > > > 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)? ENCODE_FILE can indeed trigger GC in rare cases, but I see only one such call: path = ENCODE_FILE (path); We could simply move this to before the loop that sets up new_argv[]. > 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. maybe_quit is not the problem, the problem AFAIU is that any encoding could have pre-write-conversion function written in Lisp. > >> 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. Sorry, I don't understand: why macros? Do we use something like that anywhere else in Emacs? > 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. First, the techniques that rely on separate segments are non-portable, so not all platforms will support them. More importantly, I'm afraid the amount of code where we currently don't expect GC is much more than you seem to imagine, so I don't think the above is practical. In any case, the starting point is to audit all the places where GC can happen, and that needs to be done anyway if we want to do it thoroughly and proactively (as opposed to only when someone reports a bug). We can delay the decision what to do with these places to later, when we understand better the magnitude of the problem and its various aspects (in terms of several different effects that GC can have on various objects). > >> 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. I only meant that MPS is not very different from the old GC in this regard, that's all. > >> 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. The safe thing is to re-initialize the pointer from the string whenever we think GC could happen, and otherwise make sure GC cannot happen. > 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 = string; > ... trigger GC here ... > puts (SDATA (unmarked); > > the most likely outcome (thanks to Gerd for the hint) is that > nonsensical data is printed Are you sure? AFAIU, referencing 'unmarked' is safe, even after GC. The below is indeed unsafe: char *p = SDATA (unmarked); ... trigger GC here ... puts (p); > > 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. Before we agree that this could be the reason, we'd need to find the places where GC could reuse the memory of a live string, while that string appears in some live data structure, and as long as no GC can happen between the time we put the SDATA pointers into the environment array and the time posix_spawn returns.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 15:34:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 10:34:32 2025 Received: from localhost ([127.0.0.1]:56726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tU6AZ-0006Wn-Fb for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 10:34:32 -0500 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 <pipcet@HIDDEN>) id 1tU6AU-0006WI-81 for 75322 <at> 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== Date: Sat, 04 Jan 2025 15:26:01 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Message-ID: <877c7aha9n.fsf@HIDDEN> In-Reply-To: <86jzbad735.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> <87a5c6j0qn.fsf@HIDDEN> <86jzbad735.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: be12c40dfc8ecf252b70a813a8df39329bfda6e8 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Date: Sat, 04 Jan 2025 11:08:50 +0000 >> From: Pip Cet <pipcet@HIDDEN> >> Cc: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN>, 75322 <at> debbugs.gnu.org >> >> "Eli Zaretskii" <eliz@HIDDEN> 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
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 15:34:28 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 10:34:28 2025 Received: from localhost ([127.0.0.1]:56724 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tU6AV-0006Wd-Rt for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 10:34:28 -0500 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:48359) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tU6AS-0006WG-1y for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 10:34:26 -0500 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-43625c4a50dso89465185e9.0 for <75322 <at> debbugs.gnu.org>; Sat, 04 Jan 2025 07:34:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736004857; x=1736609657; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=1vYrkTMrkVjh3O/9ZH+HsFQEN0Xl6Db95Y5M3Gb2zXA=; b=FERooB5XpKZC9VrVcQhLPcGsm33uB7c8McHinzeDqSG5BVZJc4dguiX00zvAmyw4Gu 853vMvHp+TGQZuQ7OXI/g1dQBm2wybrzeJFIkXabNv+RfyGK2IyEeZpqvFr4Em2+ouNp jvlOp15GA8TTb4tRxDEHsR+dCe1Ru747CJAEHwZhtKCIf92pdF9XLvPX1ctTeaGg4+2T NbFoXxsphWmZbpxBcXZ/25an7xw8B+eKRevQT3l0Y+ILEnMCCYhnJfrZphCS4U20ALdk tWe5RkW4YTeYQxztTIIF5nHXLTeyLYhAmuq0NsiRy/8LCOp8KB+yZRfcaGBpVXabpkgs /cWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736004857; x=1736609657; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=1vYrkTMrkVjh3O/9ZH+HsFQEN0Xl6Db95Y5M3Gb2zXA=; b=cCDd03x6CfDCuSnzo+PHQ2AaU7diN3NAMGLleINmTB2KA5O4vgDFWqqaFPHlChtN/8 aI56wwWvMlguGVAyzhGAKeh0NF+kE+DgGNur2gY944nYYyaSj754Y7WT39T9DI8IWa1s 5PAh/8G33k6bXV62weJlKRGoZ7wUEfpw0dC9nbB008Ilawnc/VbXtZD/cJZ0oaH8cbAP 6mQRyVM+D8ic5+Fnoj++bUKDXZsnOJYc7RI65pf3qLyx3uNcTLss3lAeJlo6vUrPrvRT X7sSW10ZoMORJ1DzlcijXEdBNMQ9nP7JaxKEwAudQMxG3tHOMeSETMW1w7oUxhgL70yw 9z8g== X-Forwarded-Encrypted: i=1; AJvYcCWnPx5r2Vh1O8fU7nUWYP8842iFFcbyUJkvDmMHodw/Nqd0fK0MSpS0ACd4lqKQUn2QNNb5lw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwVo+BUNNn2doWyiYFLY4GmcdD56dMAUk+Q+Mbf+jDNFZVQ5fhI Ke5o+8sR5UKJGwmtPmDikwds50/Ib20W8uYIvfDJ7wjO8UJKlgZBEqhfvg== X-Gm-Gg: ASbGnct/vG3fhhLgOeLz0CIVXjYEwn8BllRT9HfpIwHTBz9RB2Y4G8GetpGt9t3NlU+ /JKvywwvUJxhUE9cLbe30KId68khG4j1derI8VKMyFEypvBmo1yboxEDi8d63Zg6o0nlx5sGtAt HqecWjGVPBPYkwPIpvKssiq3epL7DonMi2te7sMNNmN7sosT9R85EDWW9fdhLcaD1ZF0o/BXB4z AMw99hTfA21+Q6k2wB/ThKri9RMpntLt72EwEoKCeq/+AJGgdmrM8qkOc1OVuersveM7gSJ/SwX xRbnce0Cf+eEYPJQpUQ5USEFS2acXdrHpZgHRCf67Ouii63X/10nK5ZMZpA7zVd6Og== X-Google-Smtp-Source: AGHT+IHYozgRMp3IXSWqokIgW/gJcsfVcEi2hjs5m843ogSusSQBhwfrcuduB7OgxLXzCwfc4/SCIA== X-Received: by 2002:a05:600c:5246:b0:42c:bb96:340e with SMTP id 5b1f17b1804b1-43668b7857amr487638765e9.31.1736004856957; Sat, 04 Jan 2025 07:34:16 -0800 (PST) Received: from pro2 (p200300e0b73c9f00c50ae305bf989514.dip0.t-ipconnect.de. [2003:e0:b73c:9f00:c50a:e305:bf98:9514]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43656b3b271sm546893305e9.34.2025.01.04.07.34.16 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jan 2025 07:34:16 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <877c7aha9n.fsf@HIDDEN> (Pip Cet's message of "Sat, 04 Jan 2025 15:26:01 +0000") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> <87a5c6j0qn.fsf@HIDDEN> <86jzbad735.fsf@HIDDEN> <877c7aha9n.fsf@HIDDEN> Date: Sat, 04 Jan 2025 16:34:15 +0100 Message-ID: <m2r05ik2yw.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: Eli Zaretskii <eliz@HIDDEN>, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Pip Cet <pipcet@HIDDEN> writes: > "Eli Zaretskii" <eliz@HIDDEN> writes: > >>> Date: Sat, 04 Jan 2025 11:08:50 +0000 >>> From: Pip Cet <pipcet@HIDDEN> >>> Cc: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN>, 75322 <at> debbugs.gnu.org >>> >>> "Eli Zaretskii" <eliz@HIDDEN> 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 I'm entering a state of confusion again, as usual in this discussion. Can we _pretty please_ just do the xstrdup thing, and forget about it?
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 14:13:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 09:13:18 2025 Received: from localhost ([127.0.0.1]:54019 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tU4tx-0001hL-DY for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 09:13:18 -0500 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:55715) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tU4tq-0001h8-5U for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 09:13:11 -0500 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-4361dc6322fso86227775e9.3 for <75322 <at> debbugs.gnu.org>; Sat, 04 Jan 2025 06:13:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735999988; x=1736604788; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=qy1DdBEFUyO9Jzq2PFkc2CSOm24oywR6Vl7Y471zDd0=; b=S09vbKuLy5IHrVq/Ki409FKRDWwnBIT0gflBaX9nqpo2uZYSNSz8Bfwza3RrSjsJAk 4F00smOsOxoU/YlzyaqAQbvOhyw4kJMBnrKEWY3Xt8YNUKh+k7xsrYbIvWi/MsSBUn// a9nGy3GluwKzGLcwcEezw08W0rUYFGNfQgzUYLvw+5YhD3ECTqFj6TxHu80vxlMaFVtP aqjUh/q/qIgV5GXZQPOVxVJAultf02jcdQVVBPseaCkf/RrkAaHHUMxKiyxBNf36F3o0 6J0vAI1Qi5jA7DvWEXyXkx24v6obkLp7vp/opt7r++ztMfXV0n3wrfnKYY0v0rGowUFr MbQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735999988; x=1736604788; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=qy1DdBEFUyO9Jzq2PFkc2CSOm24oywR6Vl7Y471zDd0=; b=ad+Ap1cz11ARtWXndWb0jKL9zJVpemW1mpS1+6+iYoMOLeu2W8fDliBUbALbZJ6tVO Fy7QY2s1haBVqiJmjVpO6Cxkw6qSk7zWHbrH/luwZamrOFp0fzZqDs62dUbMDyOcxjdi XQ5xLAX+5sHEP75mSWHmFkZTqc0+JyzvnDdjfis66flLgA2UzWWyTLlOaAsFYdlq7tVR Zf+nYCD0L3JUAQPK00tOSZIDPHyn2oQPljw93Uwh/QZzFKL4s2Q4lS11J2vqHHZgOgPs 9M1QTMuHpUJEDQrhU7859utM2Bpp2CWcKczB3VaNpdxDZRnOD3y1qTvxtEfo+Rr7AMuP vqBw== X-Forwarded-Encrypted: i=1; AJvYcCUuH1oWYqrYZ+CFHXwnSIlJAht2Wm3+ROx7SQDRnMGYYa7RgXaxodtGR+ZvKCRye95ZOyfAAg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxMHgdhWT3qoBUKPyUs8eXzaMvuQ39lc1KmGqgLzW7sQ+Ngcey2 8Ho8d4AIyUw/k7GSRBfecjujYKKcn4Ai5AZUeJIG8CngyC7rKhrmFLCG1Q== X-Gm-Gg: ASbGncudzvYg/MRC6gGiCB2kfAAJqyiozraXpa2WXKV20er60KcabH7K134npXXMXTE UUbUhlXOz30mRpdPMVsiRZGjdKVrg0evzL41q7apl0zMZ3pDPHR5a+8p9HdjH9aAoy8n02i4ISY aKha5gMSlajkz4nwp9n9L4YcWsPTaugbj19Nla/Fb4XrB7lfrcbjkddCC/83igjVbyPouL9jG91 Saa5jXMvR/A9gKhIPsLXya+0qqebAEj/9fWB+6TCLQfnasllBiimqAkfF2N7RD4K61KAfuxWsns 9uWZvwJmGU1qaQ5fmEWY6pjvyYgaveWzcRfSoTLQwJfkCcI2TLoyo99GCR1XAdKMNw== X-Google-Smtp-Source: AGHT+IEkqo1OkKJKV6HZt7Mxyec5DLVwi9uWjDOr4H+FDt6YJ9zr6aL6nyRThWuwA/T3sAk1dXfw4g== X-Received: by 2002:a05:6000:2c5:b0:385:f195:27f with SMTP id ffacd0b85a97d-38a221f339emr47119008f8f.5.1735999988282; Sat, 04 Jan 2025 06:13:08 -0800 (PST) Received: from pro2 (p200300e0b73c9f00c50ae305bf989514.dip0.t-ipconnect.de. [2003:e0:b73c:9f00:c50a:e305:bf98:9514]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c828a8dsm43557279f8f.2.2025.01.04.06.13.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jan 2025 06:13:07 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <86jzbad735.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 04 Jan 2025 15:47:10 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> <87a5c6j0qn.fsf@HIDDEN> <86jzbad735.fsf@HIDDEN> Date: Sat, 04 Jan 2025 15:13:06 +0100 Message-ID: <m2h66efz0t.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: Pip Cet <pipcet@HIDDEN>, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> 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. So, Ihor saw something in igc. In that case, the string _data_ will never a barrier on it, because it's leaf data, i.e. data that doesn't contain references, and that is allocated from an AMCZ pool. If that helps, don't know.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 13:47:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 08:47:25 2025 Received: from localhost ([127.0.0.1]:53945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tU4Uu-0000XK-0g for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 08:47:25 -0500 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 <eliz@HIDDEN>) id 1tU4Uq-0000X5-DL for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 08:47:21 -0500 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 <eliz@HIDDEN>) 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==; Date: Sat, 04 Jan 2025 15:47:10 +0200 Message-Id: <86jzbad735.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87a5c6j0qn.fsf@HIDDEN> (message from Pip Cet on Sat, 04 Jan 2025 11:08:50 +0000) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> <87a5c6j0qn.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: gerd.moellmann@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 04 Jan 2025 11:08:50 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: Gerd Möllmann <gerd.moellmann@HIDDEN>, 75322 <at> debbugs.gnu.org > > "Eli Zaretskii" <eliz@HIDDEN> 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.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.
Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 12:18:02 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 07:18:02 2025
Received: from localhost ([127.0.0.1]:53762 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tU36P-0004mo-ES
for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 07:18:02 -0500
Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]:47478)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>)
id 1tU36M-0004mS-Kc
for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 07:18:00 -0500
Received: by mail-wr1-x433.google.com with SMTP id
ffacd0b85a97d-38634c35129so9871588f8f.3
for <75322 <at> debbugs.gnu.org>; Sat, 04 Jan 2025 04:17:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1735993072; x=1736597872; darn=debbugs.gnu.org;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to;
bh=juWvFpCCxp8eHNP0joEHoMBlGOUfdno4URV8fbJdq2I=;
b=Pnv7yGFetMiNVrvkdhWb/WlKhpqfSPkCGO81xsfqDXqjT4ct6+bh/PUqxQ2sFMi/Mm
OLeGLlVmHQzO/smLEQfFXofV04x4l790d/kX5gclpsaA94f0B6LtZoIUCuO1vptWvUEf
BFBZ50NPt6ZcuiYjTPfNxnP0JDyw1wnMGUgRDTp1jwx/V6zoRd5rab7R71LBr0s9DkGy
Nptn1LfDHkmUbUq54uIVwsx+lThMwA7dV5aVyx0iVvpgSJnqmE8PtVkxLxSB776pppZX
wkY5FdG+5rvqrTzToTgqdzTPIlngMWGVd/kwTehyruRZwFTtrtIMzFNTAdIJyIO3gmMv
ubQg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1735993072; x=1736597872;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date
:message-id:reply-to;
bh=juWvFpCCxp8eHNP0joEHoMBlGOUfdno4URV8fbJdq2I=;
b=feHSeGybxLWq2SQyWQANFLauD2e0jJ3jU6m3SDe7IKKhEGzgxcG6yXpwDxccM2lynL
AFLXJAXRAPOpuid1d3o+DkWbieH8GbNEIxonQSu6BfHxBNxHefbiIZm95n/9aow+jNg9
+zrOKnHzn6JgHqcfZ4DhuCsRdcluF8ESGR2lc+KYcXFDNoRSTfnd0L7kMIrNBRAnPfmh
661p3lZUFhQhgjnm03ScBRH9XLJl+dJwW4rIyqrSXZZV0+8jSnVVBTG623JxCrE/ik1b
siZ6tDhTyW+FUfZXvLGPYTsjbY3mdZ9PEclCDLkpKkoCyQxUu4SbYJ2Mof/Zv/7s6ha4
yG+A==
X-Gm-Message-State: AOJu0YyV/Gi4e5fytyqzyl0p+JBze2m7aUsTkRpzzdDZyJqYEFQigj/+
4CMybNNm02iMQi/D2NEbsk6Cm/u3SRxmGyHa5In6/bnFOC5534D9bM0pBA==
X-Gm-Gg: ASbGnct5lP3BbWnt+XNk8nU74v2QdNdx6tof6hjM45xpvrKsqF5IYUexbj4LybFpTvj
B8SjdlpefDs3EYrx9SQp8rng9GhYn9bT0glBxF1gafOBxAZQCYrQ6OI2N2DhiT+iv4Pqvf3e6aY
tOOyJ71hk6STIfVTJ1ok+5VexSTRIW/eAE6OtTksYvSXpKvmD1fXmJi+hwb9zHpnVbTO/jHAdsg
7zF/xNejfyf9vyfHSHacVD+W2/TafqlIJinADb0CRlR1L+Id4G33H9t5Nkb2ZDhOCRxLtIfEeZF
cmeIGXF5GTt6OzUlDAgM7pCOK0CfSWv1YYXQueoHIRmS/D+kO4B1NccJF8soUGtTDg==
X-Google-Smtp-Source: AGHT+IFyQEvx5TODGJtuhnlfw2CeUbgHeq6x5gODxvmTZROLlzPgG13cFTZpovETANwbv3Pb038XvQ==
X-Received: by 2002:a5d:64ac:0:b0:385:effc:a279 with SMTP id
ffacd0b85a97d-38a223ff46cmr38560553f8f.58.1735993071880;
Sat, 04 Jan 2025 04:17:51 -0800 (PST)
Received: from pro2 (p200300e0b73c9f00c50ae305bf989514.dip0.t-ipconnect.de.
[2003:e0:b73c:9f00:c50a:e305:bf98:9514])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-43661219611sm516624075e9.23.2025.01.04.04.17.51
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 04 Jan 2025 04:17:51 -0800 (PST)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
In-Reply-To: <871pxiizrq.fsf@HIDDEN> (Pip Cet's message of "Sat, 04
Jan 2025 11:29:46 +0000")
References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN>
<m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN>
<m2v7uvnqdy.fsf@HIDDEN> <871pxiizrq.fsf@HIDDEN>
Date: Sat, 04 Jan 2025 13:17:50 +0100
Message-ID: <m2o70mg4cx.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75322
Cc: 75322 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Pip Cet <pipcet@HIDDEN> writes:
>> TBH, I couldn't follow your thoughts above with the EFAULT, syscalls and
>> so on.
>
> My understanding is that if there is a memory barrier in place for a
> string that a syscall tries to access, we get an -EFAULT from Linux, an
> EFAULT from glibc, and the syscall won't work.
Ah, I think I understand now, thanks. Thing is that string data is in
our leaf pool (AMCZ). AMCZ doesn't use barriers because there are no
references in its objects. Does that make sense?
> This is what makes valid_pointer_p work, for example. (To the extent it
> does: valid_pointer_p assumes 16 bytes after the pointer are readable; I
> don't see why that is true for small objects).
>
> What makes this more difficult is that glibc and GCC disagree about what
> to do with invalid pointers even in the simplest case: glibc documents
> printf ("%s\n", NULL) to work, but GCC will rewrite it into puts (NULL),
> which crashes. I'm worried that glibc might wrap a syscall incorrectly
> wrt EFAULT and SIGSEGV, in this case.
>
> Worse, if the syscall is in a fork()ed process, MPS machinery to remove
> the memory barrier might not be in place after the fork. And who knows
> about posix_spawn action descriptors? Or vfork?
>
>>>> Or one does it as you did in b0a209e9204, that's of course also safe.
>>>> For both old and new GC. (Don't remember if you mentioned it Pip, but
>>>> old GC moves string data as well, during string compaction, should GC
>>>> run).
>>>
>>> Ouch. Yes, I remember now.
>>>
>>> Pip
>>
>> And today I see you reverted that commit. Is there something wrong with
>> it? I couldn't see something wrong, and for me VALUE(no root) >
>> VALUE(exact) VALUE(ambig).
>
> There were two reasons for the revert:
>
> 1. Eli asked me not to push the change right after I pushed. I thought
> it would be best to restore the "before" state so we could discuss the
> solution.
>
> 2. For the non-MPS case, I rashly assumed it would be okay to remove the
> no-GC assumption that call_process apparently establishes (even though
> there is no comment saying so). I'm not sure what I would do now; the
> old code seems buggy to me because Fexpand_file_name can call Lisp, but
> that bug affects only argv, not envp. It may be best to fix the argv
> code but leave the envp code in its (once again) current fragile state,
> documenting precisely which assumptions are made there.
>
>> WRT Lisp_Object allocas, please tell if I should do that.
>
> Sorry, I don't understand. Lisp_Objects shouldn't be allocated with
> SAFE_ALLOCA, but allocating them with SAFE_ALLOCA_LISP_EXTRA is fine.
> Pointers to string data cannot currently be safely allocated with
> SAFE_ALLOCA, but I'm not sure whether SAFE_ALLOCA_AMBIGUOUS or
> SAFE_ALLOCA_EXACT_POINTER would be the right thing to do.
My fault: I meant allocas used to store Lisp_Object in them, i.e.
Lisp_Object * :-).
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 11:41:34 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 06:41:34 2025 Received: from localhost ([127.0.0.1]:53648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tU2X7-00036S-Q7 for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 06:41:34 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:48763) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tU2X5-000362-Fn for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 06:41:32 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735990884; x=1736250084; bh=BhEn2VJy5mfMjVHogLuM8l8xH5oemSwpYf/mt97mL0c=; 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=YCIED69fmRQGWU0ssoVgr98DyLbJw4ERU2mqZH4uDJxZHw0vxD0wfzPJiuCQw18eZ 5yWeAQXJKoihDX/Oanepm8/ldlgzo93AVeapg2v8VgrxZ4fjNFPYtO7GezTXcE1Xhd WCHZxjgYp9ofHDWUbd4qucceCEPXxjrM8sdZ47/zdG0JGJv13Kms6kavbS/T541wcF OHlxkw0K2zBSp/5wQF4CLjNNBtISbGdVfRXqnwm8Z5S4raVaLqvZgxRMTZ00+TIbQ1 kcH6HLOiDy571rrxBPazBWPAmS7P3g/We6P2KESDK32/tWmSJhv6dNKasMsQlEZd5Z 6bysyHw530a/Q== Date: Sat, 04 Jan 2025 11:41:20 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Message-ID: <87wmfahko1.fsf@HIDDEN> In-Reply-To: <865xmugawr.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 59ff7b8a13b462cd7c1e323f068beb9dfcc2eaf5 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org >> Date: Sat, 04 Jan 2025 09:47:43 +0100 >> >> Eli Zaretskii <eliz@HIDDEN> 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. It's easier to xstrdup rather than figure out which no-GC assumptions are in the subprocess code, which of them are valid (probably not all of them, considering Fexpand_file_name), and how to document them in a way that doesn't turn this area of code into more of a minefield than it is already :-) > 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. I'm not going to explain "how GC could happen" in the MPS case: GC can strike at any time. For traditional GC, if we want to change the code as little as possible, we could indeed try to establish no-GC assumptions, but we don't have to: we can simply start with correct but slow code and maybe drop a note to the usual suspects that there is optimization potential here. >> 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? TBH, if there is a single bug caused by an incorrect SAFE_ALLOCA which should be a SAFE_ALLOCA_LISP, I think that's reason enough to modify SAFE_ALLOCA to conservatively scan any xmalloc'd memory it uses. No performance impact as this case is nonexistent in practice. Pip
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.
Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 11:30:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 06:30:04 2025
Received: from localhost ([127.0.0.1]:53585 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tU2Ly-0002Tq-Tg
for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 06:30:04 -0500
Received: from mail-10629.protonmail.ch ([79.135.106.29]:37219)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1tU2Lv-0002T2-4P
for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 06:30:00 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1735990190; x=1736249390;
bh=WHjIZ0W4ASWbmuLrZY/mLmM3BlcBK1YldQpbKYwDHMI=;
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=T4eubTgPFhKwuenAOut7DillSXmZMPnFlugxnx7IWJzzITf4pF26OoVVA11oIeVMg
jHxjjaKbx7EO56llQUEJ7tvQ0o1Any2ekTXaRICOM911ocVI6w60fgKkRKILQP6Iqp
+rfwiH44cK782io769yf8a9sy7bmCuzSShPn8iPxZqlTcmmBHIYtqd/KNb8uH6eoeF
6t9iDUOXDRHEX4f6E4ZNHDzGjMyr+xoHMp5oouYTYnFazQDlSuyVmM7VSBE1/s2m2Q
OIiIiLusehGmmLp8vCsHiu2S+RainkArpBZ43HBfsa/gE7peYJpR48vBLo6pWHslPQ
o2TSIRQZHGfAw==
Date: Sat, 04 Jan 2025 11:29:46 +0000
To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
Message-ID: <871pxiizrq.fsf@HIDDEN>
In-Reply-To: <m2v7uvnqdy.fsf@HIDDEN>
References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN>
<m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN>
<m2v7uvnqdy.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: ade87087739d1b037ae0d0db3b13d056b565bdd9
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75322
Cc: 75322 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
> Pip Cet <pipcet@HIDDEN> writes:
>
>> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
>>
>>> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
>>>
>>>>
>>>> The pointers to string data case probably requires adding yet another
>>>> macro SAFE_ALLOCA_FIND_A_GOOD_NAME, which, for MPS, allocates a root,
>>>> possibly and exact one which would be good.
>>
>> Note that might still EFAULT if there's a memory barrier. I think.
>>
>> Do we really need to move all arguments to syscalls and libc functions
>> which might use a syscall into non-MPS memory? That would be bad.
>>
>> And which libc functions might use a syscall? I think we can agree
>> fprintf might, and memcpy() doesn't (note to self: destroy all evidence
>> I ever considered making memcpy() use MMU tricks for very large
>> buffers), but what about all the others?
>>
>> Maybe I'm panicking too much and fixing read/write/exec* is good
>> enough?
>
> Don't Panic! Quote from The Hitchhiker's Guide to Emacs (non-NS edition)
> :-).
> TBH, I couldn't follow your thoughts above with the EFAULT, syscalls and
> so on.
My understanding is that if there is a memory barrier in place for a
string that a syscall tries to access, we get an -EFAULT from Linux, an
EFAULT from glibc, and the syscall won't work.
This is what makes valid_pointer_p work, for example. (To the extent it
does: valid_pointer_p assumes 16 bytes after the pointer are readable; I
don't see why that is true for small objects).
What makes this more difficult is that glibc and GCC disagree about what
to do with invalid pointers even in the simplest case: glibc documents
printf ("%s\n", NULL) to work, but GCC will rewrite it into puts (NULL),
which crashes. I'm worried that glibc might wrap a syscall incorrectly
wrt EFAULT and SIGSEGV, in this case.
Worse, if the syscall is in a fork()ed process, MPS machinery to remove
the memory barrier might not be in place after the fork. And who knows
about posix_spawn action descriptors? Or vfork?
>>> Or one does it as you did in b0a209e9204, that's of course also safe.
>>> For both old and new GC. (Don't remember if you mentioned it Pip, but
>>> old GC moves string data as well, during string compaction, should GC
>>> run).
>>
>> Ouch. Yes, I remember now.
>>
>> Pip
>
> And today I see you reverted that commit. Is there something wrong with
> it? I couldn't see something wrong, and for me VALUE(no root) >
> VALUE(exact) VALUE(ambig).
There were two reasons for the revert:
1. Eli asked me not to push the change right after I pushed. I thought
it would be best to restore the "before" state so we could discuss the
solution.
2. For the non-MPS case, I rashly assumed it would be okay to remove the
no-GC assumption that call_process apparently establishes (even though
there is no comment saying so). I'm not sure what I would do now; the
old code seems buggy to me because Fexpand_file_name can call Lisp, but
that bug affects only argv, not envp. It may be best to fix the argv
code but leave the envp code in its (once again) current fragile state,
documenting precisely which assumptions are made there.
> WRT Lisp_Object allocas, please tell if I should do that.
Sorry, I don't understand. Lisp_Objects shouldn't be allocated with
SAFE_ALLOCA, but allocating them with SAFE_ALLOCA_LISP_EXTRA is fine.
Pointers to string data cannot currently be safely allocated with
SAFE_ALLOCA, but I'm not sure whether SAFE_ALLOCA_AMBIGUOUS or
SAFE_ALLOCA_EXACT_POINTER would be the right thing to do.
Pip
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 11:09:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 06:09:06 2025 Received: from localhost ([127.0.0.1]:53529 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tU21i-0001RZ-HG for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 06:09:06 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:46177) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tU21g-0001R1-4e for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 06:09:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735988936; x=1736248136; bh=mkV36oRdn43Zz9KrOQLtx+h1jjqNywwgq5tcn9Bf1Mg=; 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=CwxKVa4FGpq1qVcoF5w8tU5eCZep/chMvdjkE3p/HX1ZB2szEHm37a/DdKwmfjFVh OnW3xjtcss1KZ4oRIvczJl4L0nGj5gQETr0Wjd1s5pQP8fd9U9hCPEJK0zJ4uL1Ptm zU0j8FTBTLVN7TS05zMGPxbqvln/SbdiaFd3HI2ExffMq+MxSGoxgTtGRnHri3bI+/ yz2WYW3ws1Co10UrPmINCojy2KZI8u1vEDdgZSKz4tmQFzU7GWM6/Wo8ZyuiKDVQmW DnM2zqCI4KjDzhhlPkZPiPNNPZWGuMvSgI93I90qkMTXpM7ZwuH3PQbQTuvyz0P6Vk KFOoVKS9CbHgQ== Date: Sat, 04 Jan 2025 11:08:50 +0000 To: Eli Zaretskii <eliz@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Message-ID: <87a5c6j0qn.fsf@HIDDEN> In-Reply-To: <86sepzf4h3.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 10ba730b7ccf6fb9fc34e2fbe2773ac79190ade7 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) "Eli Zaretskii" <eliz@HIDDEN> writes: >> Cc: 75322 <at> debbugs.gnu.org >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Date: Fri, 03 Jan 2025 21:34:07 +0100 >> >> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: >> >> > >> > The pointers to string data case probably requires adding yet another >> > macro SAFE_ALLOCA_FIND_A_GOOD_NAME, which, for MPS, allocates a root, >> > possibly and exact one which would be good. >> >> Or one does it as you did in b0a209e9204, that's of course also safe. >> For both old and new GC. (Don't remember if you mentioned it Pip, but >> old GC moves string data as well, during string compaction, should GC >> run). > > 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. Regardless of what you're saying, such assumptions need to be spelled out. Where they are made, that is, not in a utility function. 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. > Is that assumption false with MPS? As we agreed, code should be written to assume GC can strike at any time. In the context of MPS, to make things more difficult, "GC can strike" may mean a full GC happens (moving objects) or a memory barrier is lifted. > 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. Pip
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 10:20:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 05:20:52 2025 Received: from localhost ([127.0.0.1]:53472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tU1H2-0007mO-Br for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 05:20:52 -0500 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:45171) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tU1H0-0007m9-2Z for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 05:20:51 -0500 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-435f8f29f8aso93496955e9.2 for <75322 <at> debbugs.gnu.org>; Sat, 04 Jan 2025 02:20:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735986043; x=1736590843; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=+4uOErmjVKuM04kD64lbqLb5qri+0NhydyRtv+c7TLc=; b=IrVfReDhskotUFWayYFnOfHaxhihx38d6lhRkV3Gy/7+GNvAvMk++WPwGzg1wfX8OE yAu/ARNfpeUGX4atLhblsBiXmO2mY4e0D9DzX0g0mZcEXN9Lb23XySOeKWOYG0+M1KVt YciK3QxPbdF+nOyOG9UKJO9ckcI6txLyXdO3OR2YRJ0HtwrU6rr3xc+vtDjvMnRsPeoX j+fP66O5dmRD9Yx3KvHah7o4vigaXwuZ5pkwwE1wEvmt7+VSoad+JSAGZ5yM7iT2FRzL RuvpZ2gDUgksoe05IO8laALpGSsQ2dHgfTmcqMWGnJi2a1uiiEvD5KmXbTMaDSHtHBHi 5VhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735986043; x=1736590843; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=+4uOErmjVKuM04kD64lbqLb5qri+0NhydyRtv+c7TLc=; b=K4whTIJJ6+/zoiUV5L5ZyLEDq9kTwb7CE/wO0dpNeX8+uZq9+4LuMcFK90O/Q/gjeQ nqj7dDVSS6WsqQ5v2fIUwHPUSdIm1v3qTdZ8022zcXnRXXeqOdNBFrMsV1flSdiVo9Iz SfwPHj8rGJ+o1bSg2846MzmXmhrV7Sf543pPFtXcM6w7TNZ7TRfI6NLul8NcdG+C3JmJ MC3zAFbIR/C/7tjp03i7gG9QT/1hgBhAizqQW8QB3RzGxgI7ckKv3jHRO1Ns3UcBjtlC txcYaPujBNKU8rbSho6LEEYS30Y/SuLbDBx1k9ckrGQOKQp4XRl8z+Y+AT9r1UncUmml w+Xw== X-Forwarded-Encrypted: i=1; AJvYcCWg3gAOjC/If+4TWGLjjnJG0BXVBwHcUh61e80ZxM2HxqYmyIHgA6JLmJ9H0UhF75MnuoeXJA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwDN6Sx+duCRkrq2UAW1eb58YPoPqWeEgv35pS/P9Mz6iEgfXoH 2sUIe3fiMH2yIkoN0vQlLNJg9Nrb5LsvFdx+UXM00CIWnnSVdd06RhACZQ== X-Gm-Gg: ASbGncvA3b4mkIqyeOyw16wnD3Au2QStP5E555NrP24jTPf6XmLnCna2T5XVV18/xqg 81mn1FUYr3ovR/aN3cOyjHLj4usyJBwumQh41SR0XVZM8wiCqaSdDfq60j76FhHGlvyX40nXAqH C6RaamahatPVpStchK0Al18zehry/R5bcl90CS5eqqmY1Nb6UkxSaJKl2mgcT8vC+61YrBA1hmF 0WPLIr1o2c3ImJ85+N1v4OC/7ZTKiIatzNr9e9BPaX4xI8jKJHUjcDn7U0nr2m8nZwC9kXTxPpN 5iYrUDpLvvY/iaHhJq9v+nu2ot6/7PrOSnrX8yLx9fQbuOqfi7IxJOB2Ke6jQwE7/A== X-Google-Smtp-Source: AGHT+IF/L94g2QYUe352HpbkTFPVVSpFn1WZxFuXnc5eUCowdh0cJf6v7OY1Zz6Fu69adS22GK4fLQ== X-Received: by 2002:a5d:5e09:0:b0:386:3213:5b9d with SMTP id ffacd0b85a97d-38a223fd110mr41465447f8f.41.1735986043320; Sat, 04 Jan 2025 02:20:43 -0800 (PST) Received: from pro2 (p200300e0b73c9f00c50ae305bf989514.dip0.t-ipconnect.de. [2003:e0:b73c:9f00:c50a:e305:bf98:9514]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c84722dsm42855256f8f.53.2025.01.04.02.20.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jan 2025 02:20:42 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <865xmugawr.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 04 Jan 2025 11:56:20 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> <865xmugawr.fsf@HIDDEN> Date: Sat, 04 Jan 2025 11:20:41 +0100 Message-ID: <m2wmfag9s6.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org >> Date: Sat, 04 Jan 2025 09:47:43 +0100 >>=20 >> Eli Zaretskii <eliz@HIDDEN> writes: >>=20 >> > 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. >>=20 >> 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. That's true. > > 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. I'm sorry, but I'm afraid that's not something for me. The possible gains are so small that I don't want to spend time checking this. >> 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? Okay. Pip talked about callproc.c and process.c. I believe process.c is the one with the SDATA. 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.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 09:56:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 04:56:32 2025 Received: from localhost ([127.0.0.1]:53428 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tU0tT-0006eO-NJ for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 04:56:32 -0500 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 <eliz@HIDDEN>) id 1tU0tS-0006eA-8T for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 04:56:31 -0500 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 <eliz@HIDDEN>) 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==; Date: Sat, 04 Jan 2025 11:56:20 +0200 Message-Id: <865xmugawr.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2a5c7ge34.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sat, 04 Jan 2025 09:47:43 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> <m2a5c7ge34.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org > Date: Sat, 04 Jan 2025 09:47:43 +0100 > > Eli Zaretskii <eliz@HIDDEN> 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?
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 08:59:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 03:59:02 2025 Received: from localhost ([127.0.0.1]:53340 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tTzzp-0003tY-UX for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 03:59:02 -0500 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:42274) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tTzzn-0003tL-E2 for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 03:59:01 -0500 Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-3862b364538so7375242f8f.1 for <75322 <at> debbugs.gnu.org>; Sat, 04 Jan 2025 00:58:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735981138; x=1736585938; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=ZVAw9WW2aVoiQKouw2L57X4aY99E2Nw8e/EHuwEJ3kY=; b=JHFWXgHIL9XGhWzFunDeb4zDLcGW9JzwvxGUeKxgM8rTn47OYl2c8SPxpPFCAZ617T fnVu/HmUKo6yIVl9aWpdnXoj9PMbuBYuMENXJzzucrLMnDXDcIlxAw/lDgSrPU9256/q QyyOo9QXI+6hqtZoS/OlBhCQ/PkNsCwTK1IJcquYbE52/MVb8zrDJhivqo/BCip9nsX9 SAbnefuZ9+IQcrPWA2Q0k0KIkejQp8zMsNU9Ok02D2Ayb0kTyFUSjAGHWq+Ee2hpXrFx So+NtklS2tr9KPm1XMgh2CQPpimg1nOf4Zmk9hhIb03FBCShzt7F+zO6VJPjQ8D1zZRY iHsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735981138; x=1736585938; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=ZVAw9WW2aVoiQKouw2L57X4aY99E2Nw8e/EHuwEJ3kY=; b=cn6m3QpZFOdoiVu6i1vPuUbqDLUmuO0RlAZni6X14NcLcMTqXn/ssAzt51Q1JBgcM/ IQLbIk+r5wiO2Msfm0vK4s7O63EliCinhv7sdNTJHbFazHWpOTHP+QyZF2wLt+mL5hle nQDcN+FOzM6xo515UNLQe6pg+WJD0FrkYU661CQicZvlFa7WKSKinG8gasTut4tnX9SQ dOdt8uiGaIYh5C5rf9FwCSLiMQNg+Hf9GquQRYcrwWLcDwlg6fB+qr6la86mGjC1y0xb NFQ8YUDkGo4x+y9Ndp0oWCeUbW8cUyog6uPeD/nMaeNGTF66ZCYchywatUc9C4l+7oPM i1iw== X-Forwarded-Encrypted: i=1; AJvYcCWRXetYwWu0M+Zu1f6quXcxdqsr7mBbibBtZsVAHnuRm9mLQ3Vv2AihoF/fItlZDHi+jpRGoA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz0zUEFyZfyuY8PT88tG0vRxd1ye/Rkb2y2AkNT6QzBArnESdMd 1Xfb+N9nqDID5+j/O/A+6xcQOSE//Z2wtz6bJz9q9uPc3j5TZXvshe1fiA== X-Gm-Gg: ASbGncsKa8s9Tj7ey4DQRySkRpCi+a9WFctV1BEA59PQNOINYM35Jrnj0antR8GejLM xv9t4g3Lp/F0NmzR2HAWrfAlMXgFaOXehWLM5JeX1UZ5LNdZk6HO3UGF0u8LeIqulGFblAmvteN /dYHgV4kxWo6V5caZGlneYJxMSsxnoS5oN9wtxYishK6Vc9v4eeaakbBTWhuKHC37PjUEGUpgc2 OPdf7OdFsXIR+xoHdWlt2XWf0sL45XRwQc/7zqkxVO425SYE0z48Cp3aaqflZ8UJhcVHnBlM45/ G+IMA34I8O8DB+6uhoGNwKjlKCrxuo8f53AZAL7mSxOQA3R9kpizjGCot3ggsZBkIA== X-Google-Smtp-Source: AGHT+IFo+asWD2Yqd4pgAo3EbJiSz/BE0wnUhxSNg2+D2GFuhtgAkA2cUR4oClHBlFzPh+HU5Wr5dQ== X-Received: by 2002:a05:6000:1faa:b0:386:3672:73e7 with SMTP id ffacd0b85a97d-38a1a1fdecfmr50086019f8f.9.1735981137701; Sat, 04 Jan 2025 00:58:57 -0800 (PST) Received: from pro2 (p200300e0b73c9f00c50ae305bf989514.dip0.t-ipconnect.de. [2003:e0:b73c:9f00:c50a:e305:bf98:9514]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4366112e780sm504648405e9.0.2025.01.04.00.58.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jan 2025 00:58:57 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <86cyh3f0mr.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 04 Jan 2025 10:23:40 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> <m2o70n120h.fsf@HIDDEN> <86cyh3f0mr.fsf@HIDDEN> Date: Sat, 04 Jan 2025 09:58:56 +0100 Message-ID: <m25xmvgdkf.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75322 Cc: eller.helmut@HIDDEN, pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org, Helmut Eller >> <eller.helmut@HIDDEN> >> Date: Sat, 04 Jan 2025 08:17:34 +0100 >>=20 >> Eli Zaretskii <eliz@HIDDEN> writes: >>=20 >> > The current code in callproc.c assumes that GC cannot run while we are >> > parked in posix_spawn or vfork. Is that assumption false with MPS? >> > If so, what would trigger GC during that time? >>=20 >> Okay, so it's safe with the old GC, I assume. Do you know if it is done >> with an inhibit_garbage_collection? > > No, without. Unless posix_spawn could somehow call back to us in a > way that posix_spawn will later return and resume running (as opposed > to via a fatal signal), how could GC happen? > >> Not that we run into the trap that somewhere on the way to the >> actual fork maybe_quit is called which can GC and so on, like we had >> it in the regexp engine a while back. > > This can be established by examining the code, right? In principle yes, one could check if maybe_quit is called in the call trees between the point SDATA is stored and fork happens, but I wouldn't do it because (1) someone might add a maybe_quit at some point, (2) Pip's solution is immune to the problem, and (3) it's potentially a lot of work to figure out if GC can be called in a call tree. >> For MPS, I don't know for sure. I have seen in passing while git >> grepping in their repo recently, that they write something about forking >> and child processes, but I don't know what they do. Maybe someone having >> read the code can answer that. (Added Helmut in CC). > > We are talking about vfork, not fork. In our case, the forked process > runs a completely separate program, in most cases not even Emacs, so MPS > has no bearing on that, I think. Okay. I hope Helmut and/or Pip know more about this than I do. >> > 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? 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. >> > >> > If 'globals' is not protected, I think we should protect it, no? >>=20 >> process-environment is a DEFVAR_LISP, and is root in both GCs via the >> staticpro mechanism (staticvec array). > > OK, so it's impossible that some member of the process-environment's > list will be GCed, right?=20=20 Right. > AFAIU, Pip was considering a situation where some of these member > strings are GCed, and then subroutines of posix_spawn use a bad > address, to explain the error message Ihor reported. This seems > impossible because process-environment is staticpro'd, right? I think that scenario cannot happen in this case, right. I'd like his xstrdups better anyway, so that all becomes irrelevant for both GCs. Less to worry about :-).
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 08:47:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 03:47:55 2025 Received: from localhost ([127.0.0.1]:53324 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tTzp5-0003Qq-46 for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 03:47:55 -0500 Received: from mail-wm1-x32f.google.com ([2a00:1450:4864:20::32f]:60883) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tTzp2-0003QZ-1w for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 03:47:54 -0500 Received: by mail-wm1-x32f.google.com with SMTP id 5b1f17b1804b1-4361f664af5so145860515e9.1 for <75322 <at> debbugs.gnu.org>; Sat, 04 Jan 2025 00:47:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735980465; x=1736585265; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=4Yj+8I2z5A+PSLLRq8Z4MtH7FTc0sIX18Mc/h4EdC6w=; b=V8rm3z6xP2Z4miVqlilQQFlkfDfHjO0l6HEooLpuBzkL/+vPl5i/VQpA3gzZ+J0l2M nGMRpaisWXJ9Zb4jZlnVkQPXc3TpXNORuOlMyW5ZeJrCTsQVnlPea06CIXjHokGBtGCP 2rUzGMwTgHQWVA6TvcBrBQ6yE5dpy84l1p+5Ah8NKSGqIOdYHWkA1wYi/szbsDjaZ5sB AT+VwxJK51ldEiS3CiJyg5dHNq9syhhexQdb3grXuX0Zr9XyxDMyZUof8c0avNoooL6d XOyV9JCd8/CAT7EAOZ9ASz8uiI3WE3wlsLc1eeJKzehioK4yYiS5yOYdKe+qp8cZbD6G DOkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735980465; x=1736585265; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=4Yj+8I2z5A+PSLLRq8Z4MtH7FTc0sIX18Mc/h4EdC6w=; b=DgwelZ7+tohFBDdopCkDTySnjCNyxQHzhKmmSNCLEWAJ432OJOxUpBuA739yV6WZTc Z0tFRZuyd6+Mz4uPUezECYUTaa93wBN7ylHrpw/xOU4eUWeW7GdgTXXtu+UkVmGmnR97 jyngD65KkO3FwFtQWlbFC2CcklWBJIga/97K3QbERRJN1BW6xdxJNLi5V3bK24jTB241 1Q4JaFou+pvnYH0pQATOEnQbJ8pFpznc88pf4Xfx76kwTQ1bRmWK6NSLr/RMr/do99ju 3lr8j4yLEMYE6YnEOesr/5pXuOB0B7/OvM1xkZ7T/7r3fVvzOSVEnlQCEpifrxO/+cyd CxiA== X-Forwarded-Encrypted: i=1; AJvYcCUbQgiUGPYT3xIRWgPaDwjJfPfyNTX5k2OfKV+SfxkezZExRg8Hl0C+1i99Mn6jl3WU/2vGqg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzLcUXzRuLrXP1oC3Dce0CdA7KtHdQb2lw0/IVjgkD35PU+9kdo AtZAlakvgaBH0b28AFDYNrDwlVuUvHGtrA3b3XM2USI7qu3OhDYipgkE8A== X-Gm-Gg: ASbGncvOOrTMnvXW0xLKfePnsqQ6G62H3aw/U3TByaW74WsFRgpW8KIk0P8eXm+z/QE /7KzHdy9ZOEJ7o41AAdimzDYsgk3Bf2i6kOVAggoilUqlMCRFoFdwDbOc1s0P32ck4CWt8g8QoF Q6N5E0a57A2xVP/EIMv52tDPSU6pL6WQs+DQONhffeOcb0ohCLLyE1I5NGTXbo29Mq2ZkpT/bTu gJIK+2IS/omY3NwW2b/FGabFYV7a0ZwWp8oVNXOtfleh5iTy/ipV4Dd6ftEgcv15Z6Lzrq0JjBV z03avO76+M7HXvoveqlOC2+nLkNG8AgrEdc49JFNcOFrNv2WR1ehRh6KXmXbzRRM/g== X-Google-Smtp-Source: AGHT+IH5J4yqFxsGMjEQtM95sLQeMck+A15rhNVdzGUY1sEtaHFWIDpFkX448zHqGoVyYA/hTVsi9w== X-Received: by 2002:a05:6000:4617:b0:385:f07b:93da with SMTP id ffacd0b85a97d-38a223f9e53mr37708455f8f.47.1735980465399; Sat, 04 Jan 2025 00:47:45 -0800 (PST) Received: from pro2 (p200300e0b73c9f00c50ae305bf989514.dip0.t-ipconnect.de. [2003:e0:b73c:9f00:c50a:e305:bf98:9514]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c829015sm42663780f8f.13.2025.01.04.00.47.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 04 Jan 2025 00:47:44 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <86ed1jf1tp.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 04 Jan 2025 09:57:54 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> <86ed1jf1tp.fsf@HIDDEN> Date: Sat, 04 Jan 2025 09:47:43 +0100 Message-ID: <m2a5c7ge34.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> Cc: 75322 <at> debbugs.gnu.org >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Date: Sat, 04 Jan 2025 05:40:09 +0100 >>=20 >> And today I see you reverted that commit. Is there something wrong with >> it? I couldn't see something wrong, and for me VALUE(no root) > >> VALUE(exact) VALUE(ambig). > > That's my fault. I asked to post the patch and discuss it before > committing, as these are delicate issues where I prefer that we all > are on the same page before changing this code. Ah okay, that explains it, I missed that discussion, sorry. >> WRT Lisp_Object allocas, please tell if I should do that. > > 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). 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.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 08:23:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 03:23:52 2025 Received: from localhost ([127.0.0.1]:53281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tTzRo-0002II-AQ for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 03:23:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51806) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tTzRl-0002I3-CD for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 03:23:50 -0500 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 <eliz@HIDDEN>) id 1tTzRf-0000gt-Qz; Sat, 04 Jan 2025 03:23:43 -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=iE2Z6/AqxzMy9Bm1yO/MkCIhyQ0RDS0OA/34wOZoSz4=; b=hFRORV5KaBipuVbMqNTM X8sT6BHmLPASLRMxgg6Jezfl15JGFgBG3REHdcQ1PEJD7qbtZgSgnq5n7QhakyQLJ3J7bWg7FvoXk nWEZ2CHZqThOr7edQNuwFRL+Tg/PY9fECTKfgzDyefVlc2afUYSPIuhxy6MK3kmv4t3duJ/423jqB BUJ2mOLe6aG+vi81tTalM0sVW7rqJQyxswMSmAY0DV0hVtB8L6gqiscjGMmK/vKJ1xZ6eCzYlzIPr AzM+iS5CiPAqZYFQhoXMFzeZc32mHgmT08/InvOtTdubaR/twGYR4jIVu3T1E1b7tsopuQSZC65uq MKgmZ7m89gnN6w==; Date: Sat, 04 Jan 2025 10:23:40 +0200 Message-Id: <86cyh3f0mr.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2o70n120h.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sat, 04 Jan 2025 08:17:34 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> <m2o70n120h.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: eller.helmut@HIDDEN, pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org, Helmut Eller > <eller.helmut@HIDDEN> > Date: Sat, 04 Jan 2025 08:17:34 +0100 > > Eli Zaretskii <eliz@HIDDEN> writes: > > > The current code in callproc.c assumes that GC cannot run while we are > > parked in posix_spawn or vfork. Is that assumption false with MPS? > > If so, what would trigger GC during that time? > > Okay, so it's safe with the old GC, I assume. Do you know if it is done > with an inhibit_garbage_collection? No, without. Unless posix_spawn could somehow call back to us in a way that posix_spawn will later return and resume running (as opposed to via a fatal signal), how could GC happen? > Not that we run into the trap that somewhere on the way to the > actual fork maybe_quit is called which can GC and so on, like we had > it in the regexp engine a while back. This can be established by examining the code, right? > For MPS, I don't know for sure. I have seen in passing while git > grepping in their repo recently, that they write something about forking > and child processes, but I don't know what they do. Maybe someone having > read the code can answer that. (Added Helmut in CC). We are talking about vfork, not fork. In our case, the forked process runs a completely separate program, in most cases not even Emacs, so MPS has no bearing on that, I think. > > 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? 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. > > > > If 'globals' is not protected, I think we should protect it, no? > > process-environment is a DEFVAR_LISP, and is root in both GCs via the > staticpro mechanism (staticvec array). OK, so it's impossible that some member of the process-environment's list will be GCed, right? AFAIU, Pip was considering a situation where some of these member strings are GCed, and then subroutines of posix_spawn use a bad address, to explain the error message Ihor reported. This seems impossible because process-environment is staticpro'd, right?
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 07:58:08 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 02:58:08 2025 Received: from localhost ([127.0.0.1]:53233 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tTz2u-00016h-9r for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 02:58:08 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:46468) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tTz2o-000166-Jp for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 02:58:06 -0500 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 <eliz@HIDDEN>) id 1tTz2j-0006BS-9L; Sat, 04 Jan 2025 02:57:57 -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=tL8YUjWVbv6PZXkeiS68PYSzA2H144apaUEpJ1Y2G3w=; b=qQ7+Eu944rhNgDV9OYx2 8p/vYOvP2QD8zwAeNl0OhODFf1Z+q0rWogiluGb0zwO/lIx5dh2dXCFf/GtkDTKpQT02lrJpdQ11u njSPoapts7HJALvN4FWTqqwVgArsOfoS2alkP6O58h6rQWV2BzSzuB5td7icngDWBam3+Xxwe5VFv VHJzVblpC5n3DaHhw3jfFWswcObS8+0IV3p3gZy/sdSTHoBRugFA2BrA46CgFiX2ZhVT1l2BybTPL hNciMJ/Cp6Dn5seiH6u6OZb4Oeke0obSAp0mzmjzHZittVSTAFoZvJpiUl1gSZw33DWPbGkzHuZZn vwADlCQxN1TMVA==; Date: Sat, 04 Jan 2025 09:57:54 +0200 Message-Id: <86ed1jf1tp.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2v7uvnqdy.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Sat, 04 Jan 2025 05:40:09 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> <m2v7uvnqdy.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 75322 <at> debbugs.gnu.org > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Date: Sat, 04 Jan 2025 05:40:09 +0100 > > And today I see you reverted that commit. Is there something wrong with > it? I couldn't see something wrong, and for me VALUE(no root) > > VALUE(exact) VALUE(ambig). That's my fault. I asked to post the patch and discuss it before committing, as these are delicate issues where I prefer that we all are on the same page before changing this code. > WRT Lisp_Object allocas, please tell if I should do that. 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. > (I think this all could also be done on master, but since this is there > forever, I don't think it's absolutely necessary. Agree?) Exactly my point, which is why I think we should discuss these changes before installing them on the branch, let alone on master.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 07:17:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 02:17:47 2025 Received: from localhost ([127.0.0.1]:53162 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tTyPq-0007bb-Ta for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 02:17:47 -0500 Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]:42448) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tTyPn-0007bC-Vc for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 02:17:44 -0500 Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-4361b6f9faeso77632925e9.1 for <75322 <at> debbugs.gnu.org>; Fri, 03 Jan 2025 23:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735975057; x=1736579857; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=wjVkn9ihEL3DYVUqlzAlUq/a9vqMBKwjlRYtgsg6WLM=; b=dJj/C70EZ5z3iClCD+uzBt0XcsysM9U4TC44GWlQmyvekjeKtsRunhFIhO+zdj0H+X I33cFX+24SLyva/azdQdR8hbWoqleVApcCIal/nBRIozYrP3+nfhdiRaS/fd/xmaWWsm I80fnAgMOR0irVhAneVwjS3L0F7y8p/69u+FY9vasNvhHxINpj9KaW6DlHEOCBnWX7eS pAeSXhX9KaKNjP8RdqDyV/ddfIdk+rfFiPh+FIaCr+lcsSRrKwgYnCaBqzm8mDxdOpzl XTO4OnD+mbzUOkyliyBAZljfgeeyxtBH6H+KHhHho/t1zERBCSQJS/M3LNZuhG/Dg/au zrFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735975057; x=1736579857; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=wjVkn9ihEL3DYVUqlzAlUq/a9vqMBKwjlRYtgsg6WLM=; b=wk3ipIwCxlf3ydxuPlc43pI15OJanbgTqMyXNG0bWg9i9nsFo+ZJW+pfValSATgm3Y B5hqWwHPSwBp+2lUu5iPP/+8kTjrj4ScHvgU73Y+qg841pidsfG3vjlqG2vZS06RLozP kBPM1rihrGfYhFl0F6gdpKswr63H7z7rnOKrPFFA2D76qWDLxpDIllfPuKKb61Fd1XRn tFEFevjoDpsvIlannUpfSvP2eQtxVTgiDEQyfMcxH1Wc51HX46I/Hwc+acEWpTJT7tTp oKBNAKIdIbBucMrg5hTiIfc8w6mS+ieVJ9lqy8/TKwE4/d69lUBzIgeIXUaG4HH/En5W 8pLA== X-Forwarded-Encrypted: i=1; AJvYcCUmaeMV5ce31Ek7dcQe3rxZDE88PO5OEgm1IWRsl8CcU2F2DAFPHt6WFBihl2IEKo8yK1f3Cg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxjNdWJbgglkCbzgCUyeXN76tnxeXZCBLKKQRjOwsW/yuZSJ/EB 9D2mU4ATHJds8wTCrYaKoXzNgXSyg5UiYhOB/3TP1lwsp9ApZmhR X-Gm-Gg: ASbGnctMb6QHOK7yguMZ5jokCHZHakFwVG04rB8oZcNirmhBIfWf/gtvPGXFbAKNNqO V9rQEfdjMs8/AtZSEO3YsWax7/3PyHHMDC1icWWjGFdu9gJbf1JMfKpIzryp8kcJXbRPwQwAYth Xn6Cz9+Wu6nP2BsV//dOzr2+zglqv5KwRdPPufeYiyhpJBQB408ZKgh/IE1R6RPQs2lcCiU0WyF KjDbMU/1L0zlKHY1KCQ5EKz8G0jZxMq2GiYU4w2xOMZBL4X1QaBmALhHn9KZ+Pv9kLlPiJ0qrEK 54iy4gGHsBgjBRm78mBx0SH9wpYyiPx8bIPsPzJajKQHXoX6dK60S3J0sCql0IekoQ== X-Google-Smtp-Source: AGHT+IEAdFqgsaBRkan8cQqJAyCg3E5nDrcNZWkRK2TgFoHzpKtqZzOmV3UcRWQKK+3ov1Cq8Kuy+A== X-Received: by 2002:a7b:c450:0:b0:436:2155:be54 with SMTP id 5b1f17b1804b1-4365c763d81mr453631365e9.1.1735975056938; Fri, 03 Jan 2025 23:17:36 -0800 (PST) Received: from pro2 (p200300e0b73c9f00c50ae305bf989514.dip0.t-ipconnect.de. [2003:e0:b73c:9f00:c50a:e305:bf98:9514]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a1c8472casm43222939f8f.45.2025.01.03.23.17.34 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jan 2025 23:17:35 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <86sepzf4h3.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 04 Jan 2025 09:00:40 +0200") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <86sepzf4h3.fsf@HIDDEN> Date: Sat, 04 Jan 2025 08:17:34 +0100 Message-ID: <m2o70n120h.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: Helmut Eller <eller.helmut@HIDDEN>, pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> Cc: 75322 <at> debbugs.gnu.org >> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> >> Date: Fri, 03 Jan 2025 21:34:07 +0100 >>=20 >> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: >> >> > >> > The pointers to string data case probably requires adding yet another >> > macro SAFE_ALLOCA_FIND_A_GOOD_NAME, which, for MPS, allocates a root, >> > possibly and exact one which would be good. >>=20 >> Or one does it as you did in b0a209e9204, that's of course also safe. >> For both old and new GC. (Don't remember if you mentioned it Pip, but >> old GC moves string data as well, during string compaction, should GC >> run). > > The current code in callproc.c assumes that GC cannot run while we are > parked in posix_spawn or vfork. Is that assumption false with MPS? > If so, what would trigger GC during that time? Okay, so it's safe with the old GC, I assume. Do you know if it is done with an inhibit_garbage_collection? Not that we run into the trap that somewhere on the way to the actual fork maybe_quit is called which can GC and so on, like we had it in the regexp engine a while back. For MPS, I don't know for sure. I have seen in passing while git grepping in their repo recently, that they write something about forking and child processes, but I don't know what they do. Maybe someone having read the code can answer that. (Added Helmut in CC). > > 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? 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. > > If 'globals' is not protected, I think we should protect it, no? process-environment is a DEFVAR_LISP, and is root in both GCs via the staticpro mechanism (staticvec array).
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 07:00:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Jan 04 02:00:52 2025 Received: from localhost ([127.0.0.1]:53136 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tTy9T-0006to-MY for submit <at> debbugs.gnu.org; Sat, 04 Jan 2025 02:00:51 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:42648) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1tTy9Q-0006sx-L5 for 75322 <at> debbugs.gnu.org; Sat, 04 Jan 2025 02:00:50 -0500 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 <eliz@HIDDEN>) id 1tTy9K-000642-FH; Sat, 04 Jan 2025 02:00:42 -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=75TKJ/iQ4bjzYK1Mwe9ffv3G1WINXCnTvEugBxsgoog=; b=Nf27+fwmAqEPivJt9bVv s2wB/tHwCSAmWGzA085o+JPonhwRKfRgi2Pk29HlsvscNVOpYvFPH5036DpuJAKeL/wMWXVgkX3Ut 4JL+PDHxFcbrnhhDMrkxItzYRGiIKtboNGm2hZPUWmMonbY9N8eZSSY23mnmQ3QD0HjckZQc2JAFa Xz/cTel/uS8jwwKDWu5qTiqQz9egqHdxm8OePn7NeNag9dFCp5PKXAdzrnXJ9UFFwkiYUqNZnKT7B ZdtQFWNTgI2ku1BD3Un/Y2jnttmLihGf//B4N6ue+6irGqAP3rdtvf5GxaLN9HSQ+YeKkhCbBJqNb KGPZDcFvF8ObpA==; Date: Sat, 04 Jan 2025 09:00:40 +0200 Message-Id: <86sepzf4h3.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2o70nfxhc.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Fri, 03 Jan 2025 21:34:07 +0100) Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75322 Cc: pipcet@HIDDEN, 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Cc: 75322 <at> debbugs.gnu.org > From: Gerd Möllmann <gerd.moellmann@HIDDEN> > Date: Fri, 03 Jan 2025 21:34:07 +0100 > > Gerd Möllmann <gerd.moellmann@HIDDEN> writes: > > > > > The pointers to string data case probably requires adding yet another > > macro SAFE_ALLOCA_FIND_A_GOOD_NAME, which, for MPS, allocates a root, > > possibly and exact one which would be good. > > Or one does it as you did in b0a209e9204, that's of course also safe. > For both old and new GC. (Don't remember if you mentioned it Pip, but > old GC moves string data as well, during string compaction, should GC > run). The current code in callproc.c assumes that GC cannot run while we are parked in posix_spawn or vfork. Is that assumption false with MPS? If so, what would trigger GC during that time? 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? 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. If 'globals' is not protected, I think we should protect it, no?
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 4 Jan 2025 04:40:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 03 23:40:18 2025 Received: from localhost ([127.0.0.1]:52953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tTvxR-0000Cb-Jn for submit <at> debbugs.gnu.org; Fri, 03 Jan 2025 23:40:18 -0500 Received: from mail-wm1-x32a.google.com ([2a00:1450:4864:20::32a]:58775) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tTvxO-00009g-Pv for 75322 <at> debbugs.gnu.org; Fri, 03 Jan 2025 23:40:16 -0500 Received: by mail-wm1-x32a.google.com with SMTP id 5b1f17b1804b1-4362bae4d7dso91977075e9.1 for <75322 <at> debbugs.gnu.org>; Fri, 03 Jan 2025 20:40:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735965613; x=1736570413; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=FYqJ0EdsWK4iVPDEDzIe+UERa5m3YZoEX76qNa/KPdA=; b=Ltyh0KFi9GQn1wmYt1nZPLWpgTtLXAYNrb1hdmUXOAkWsnYA1ry/AErbdFqG+Ch9OB Tz3E7prIAFWeF1Smym7GNtpQGbQTWkwlfEeo/dPYb2O5PESejPNqsjrYR5TjJBIm0PTl ksB6NqRee1Rf83o7/W25abwJV06pZYhlh4x0oq7cijaAnUqCNwjEzCildZLVnNnIOv/F Ry5iDCYqyxJWXglrsPKg2J0qonP+pk1V3kmKUHH+Om8Hfe+dQ7hIks9mH3JalJslpko0 9LtaEoeG73I2uCroDQq4dSGeQxa/rQIo7QjGZ91TNDT9pL1M13df4iHqKd3cDD9xVRgA D4xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735965613; x=1736570413; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=FYqJ0EdsWK4iVPDEDzIe+UERa5m3YZoEX76qNa/KPdA=; b=mYvZeMsAmNbcG/X8jS4A+geDDJ6biKfGv6P7ckiUhG4EpzE3bDXhpJ9HseQwJD3aze 7X8KgGieiYmw9vLfPkx91isMWwlkFiPToNsmKjYNgwPR3LeX8vCDk0/wgR0pqyBvMNhb EYH1/Qh1s5wcNS5IoWXfpF862Tc0aBdMudVGaC3CEj+J24YVkwCk3lgPp6ZcfgDe7kT7 v2LvXtVCCbDIfSuxFEW0qFjznBBRMlDZivB/v1IN5OxMA/h4O9ZMrWvoVWEW0wHFp/f9 aWJOt3ZWL9kbH6pX1pAplWTMBR5U8eKqk6trp+Fnd1JXKbpUO59OMw9YZ5vWbwadIK6R cSlA== X-Gm-Message-State: AOJu0YyegDa2b/1xl2gaPacFOI+DkjgI63CYYkzpGB7ritZr/faZjhSp bF4dpegqrUEEXshrDYJsgqGpBHyRU4sBeZiy0FyYIzRaQxQIpbveEjI10g== X-Gm-Gg: ASbGncvd/C87ZMqrHF2l34BJFInkxueJtwcYFqaJ6r/Yzh/+R90ZqmVzbrNTCrNfGXg kl7puLoQjJJd9zSocGMSprC2KKqhjgRiQ8capZVszIdLAZrlJplT66vQ/3MalDuUkcBow2wLiu4 1ZttlCWkhMdB2xya2mzkwqZQivbrPG0Qh1e/oroX5d8FqXSJ8m/DgaT74AeO22dtUzSPtWalplD tS/biRKT3KuMQmRi3EqsZo+D8+rbOWqY5YC5upo4p2DOPEjVjrvXztgtYwWq9/A2m08pXi2EiCJ 9FtIEebpcowwGDnef1ZMQstzakq4nynDPIZOdxmuqstdvpX5ltHNGI3R3Bn8BgkCfg== X-Google-Smtp-Source: AGHT+IHpvxI0bfvVBN8U8kkpJkYdLrReQwx3y184SWgpTdCy3C4ttZFZnduo6KyETVqyepxDoZVkVA== X-Received: by 2002:a05:600c:1d03:b0:434:a5bc:70fc with SMTP id 5b1f17b1804b1-43668642e70mr409409235e9.8.1735965613102; Fri, 03 Jan 2025 20:40:13 -0800 (PST) Received: from pro2 (p200300e0b73c9f00c50ae305bf989514.dip0.t-ipconnect.de. [2003:e0:b73c:9f00:c50a:e305:bf98:9514]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-4365c08afcbsm511365765e9.21.2025.01.03.20.40.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jan 2025 20:40:11 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <87msg7iq0o.fsf@HIDDEN> (Pip Cet's message of "Fri, 03 Jan 2025 20:48:08 +0000") References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> <87msg7iq0o.fsf@HIDDEN> Date: Sat, 04 Jan 2025 05:40:09 +0100 Message-ID: <m2v7uvnqdy.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Pip Cet <pipcet@HIDDEN> writes: > Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > >> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: >> >>> >>> The pointers to string data case probably requires adding yet another >>> macro SAFE_ALLOCA_FIND_A_GOOD_NAME, which, for MPS, allocates a root, >>> possibly and exact one which would be good. > > Note that might still EFAULT if there's a memory barrier. I think. > > Do we really need to move all arguments to syscalls and libc functions > which might use a syscall into non-MPS memory? That would be bad. > > And which libc functions might use a syscall? I think we can agree > fprintf might, and memcpy() doesn't (note to self: destroy all evidence > I ever considered making memcpy() use MMU tricks for very large > buffers), but what about all the others? > > Maybe I'm panicking too much and fixing read/write/exec* is good > enough? Don't Panic! Quote from The Hitchhiker's Guide to Emacs (non-NS edition) :-). TBH, I couldn't follow your thoughts above with the EFAULT, syscalls and so on. >> Or one does it as you did in b0a209e9204, that's of course also safe. >> For both old and new GC. (Don't remember if you mentioned it Pip, but >> old GC moves string data as well, during string compaction, should GC >> run). > > Ouch. Yes, I remember now. > > Pip And today I see you reverted that commit. Is there something wrong with it? I couldn't see something wrong, and for me VALUE(no root) > VALUE(exact) VALUE(ambig). WRT Lisp_Object allocas, please tell if I should do that. (I think this all could also be done on master, but since this is there forever, I don't think it's absolutely necessary. Agree?)
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 3 Jan 2025 20:48:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 03 15:48:24 2025 Received: from localhost ([127.0.0.1]:52385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tToam-0000Za-BT for submit <at> debbugs.gnu.org; Fri, 03 Jan 2025 15:48:24 -0500 Received: from mail-10629.protonmail.ch ([79.135.106.29]:26843) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1tToaj-0000Z9-A9 for 75322 <at> debbugs.gnu.org; Fri, 03 Jan 2025 15:48:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1735937292; x=1736196492; bh=bJCKhJ4D/rCfgmTzQCMyeOV2oe8+V9h8uE/3fLT2vCQ=; 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=LyjNfH7WI+VWKiA8w4ClZ4kbK0+xaOF8FuC4m4Qoht66OpHrGvh+xtvNVJR7MmOfa JtPeqGq6x4QmQ2lME/UgW6ODR0rfSIVdXYD8iNYeNuNe+3geWf+SP1UZvICzO/p9bI 7eWT8qChGcpM8kxyJMpmXX+pmhPspOWG7b8tKzh4TM1dlRm27fSsneZKWp8QZ49BkL wxUquUwlzy5j1XnXcVMc50ycEg3oktZy7IyStU3pgo6skafjA3HBSQOSvo3lbrLNED rO7jsoBXJPN/ZI/GUSPELXhzwEdUw1f7Nr7rjgZLquzpB/cppxTMJB86TbPWqoWrIm 5WDsMULhTJIZg== Date: Fri, 03 Jan 2025 20:48:08 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Message-ID: <87msg7iq0o.fsf@HIDDEN> In-Reply-To: <m2o70nfxhc.fsf@HIDDEN> References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN> <m2o70nfxhc.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 7e6e606440186197d698c8573d3300ebb0cd2064 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > >> >> The pointers to string data case probably requires adding yet another >> macro SAFE_ALLOCA_FIND_A_GOOD_NAME, which, for MPS, allocates a root, >> possibly and exact one which would be good. Note that might still EFAULT if there's a memory barrier. I think. Do we really need to move all arguments to syscalls and libc functions which might use a syscall into non-MPS memory? That would be bad. And which libc functions might use a syscall? I think we can agree fprintf might, and memcpy() doesn't (note to self: destroy all evidence I ever considered making memcpy() use MMU tricks for very large buffers), but what about all the others? Maybe I'm panicking too much and fixing read/write/exec* is good enough? > Or one does it as you did in b0a209e9204, that's of course also safe. > For both old and new GC. (Don't remember if you mentioned it Pip, but > old GC moves string data as well, during string compaction, should GC > run). Ouch. Yes, I remember now. Pip
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.
Received: (at 75322) by debbugs.gnu.org; 3 Jan 2025 20:34:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 03 15:34:14 2025
Received: from localhost ([127.0.0.1]:52339 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1tToN3-00083N-Je
for submit <at> debbugs.gnu.org; Fri, 03 Jan 2025 15:34:14 -0500
Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:59747)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>)
id 1tToN0-000833-KO
for 75322 <at> debbugs.gnu.org; Fri, 03 Jan 2025 15:34:11 -0500
Received: by mail-wr1-x42b.google.com with SMTP id
ffacd0b85a97d-3862d161947so6058694f8f.3
for <75322 <at> debbugs.gnu.org>; Fri, 03 Jan 2025 12:34:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1735936449; x=1736541249; darn=debbugs.gnu.org;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date
:message-id:reply-to;
bh=9m6PJGQ60g+YLBRxAouuYbyfDi3ZUCznIplT+JVB1Zg=;
b=QJ4oCi7mBocNKxPPIE5eeJ94eEuJaQDHhPVwhtRDxpohv1tvYyt1zCIgQha8zLqchq
IghinLoFpeqz54UE0rwP6x+KzJPtCGC8T66kXHy0lzNuYgmZwKYLWDAjDeqpsVpxvaLj
y/TSk5KGPSQXmkq9vK3mNKlfoP520dbGXCuGxNArtan7s4c7B+Ligs+NXri9hgwMJyCw
UZ/Ouv/9UKSXNCW+bBKBple9O1AETlxHllfu2JNdgUm+d5F4V9G2BWFwKL/Rf74a0GSW
CCL96o9niAWZ8DL+3x2+Pkxc9tWgX1h+9tQ0qPNfq5F68uZ/OMXYqmFnKcxr1FG7tirx
DjvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1735936449; x=1736541249;
h=content-transfer-encoding:mime-version:user-agent:message-id:date
:references:in-reply-to:subject:cc:to:from:x-gm-message-state:from
:to:cc:subject:date:message-id:reply-to;
bh=9m6PJGQ60g+YLBRxAouuYbyfDi3ZUCznIplT+JVB1Zg=;
b=KH3XsMnSE7A+UjVDDQrSHDoViWs2XrH1vWEbJa5hGd9QxazC11NsUNs0f6sFtwJCr7
3iNn6Ji29m3liRKeAf3FsCHjcRaR0W9FPiD9M48LC7+HwlQ+UTACLWmR0cgf4rV4QIUb
J67zP72PXleXRG/i8HQNx6QMV73CzMcZ8j7R3qT9c6suUS7AHu4hldxK1Zh2ifkH/coF
HA2eQw2N7wIiJ2+hmggsE28qntz2FoA4GaccCIjkFnXtfp6K7ptxyvfSWfIlBELiTjz7
REeRYiPQAXIUfambu6SjhJXMFp0tmXnkTMU7qa5gQg2A4tb8SVPI5cl4phEWTmHJH7kc
0wAw==
X-Gm-Message-State: AOJu0YyPoJjLmySHvA8Ge6TuveVtAZUf9K9I3Xn7qXk4tW7xHv+TWTIt
GFoIHdjsZVtLwJtl6LnknUdaKtzm8LJ+WVxROWl9rOknibyQ9O8Qd1aN7w==
X-Gm-Gg: ASbGncsiNcbEF3mTXGwxpxFyiPf1IsP6naZ7WTR5l2B9agxVEqLhqBshN189uFveTG0
GWLkRg+bfU9XhOnbJzrfZlXQGzo+z5dngc/kA4xtwjT/Hxds9r2gQ1lGdGW1MhaCNvVDnMKEBVJ
1sR0ozCE9B1YCfBF9fEBSsyF/kAmodVS/YqPz+bSYwIkhyfRK10cw2px6Kf1+boAAfUsGK6uhtr
/b4u/JJlT6ayPo7xGfBx47pemYUdqUdzdtbhRZyyu9Dh2ArCYOfFNC5f46KelHJ7k8n6MlP2W0w
ponRmZNJv+q/TPRg7Ml9t/2qu8QUbeoJhmrTMMPRD9cG/aL3vHZ2MIOA1D5oTWt9Cg==
X-Google-Smtp-Source: AGHT+IHKIYaKYv89TjIT92GQXwvHHIlefRc5Xu/33Q1JlhLlQey6/GWfJ0rkypdPeXv858Jot60Urw==
X-Received: by 2002:adf:ae42:0:b0:38a:418e:1177 with SMTP id
ffacd0b85a97d-38a418e1435mr24240795f8f.11.1735936449026;
Fri, 03 Jan 2025 12:34:09 -0800 (PST)
Received: from pro2 (p200300e0b731ca00a950f63ba10c4b41.dip0.t-ipconnect.de.
[2003:e0:b731:ca00:a950:f63b:a10c:4b41])
by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-38a1c8a6ab1sm42480063f8f.87.2025.01.03.12.34.07
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Fri, 03 Jan 2025 12:34:07 -0800 (PST)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string)
In-Reply-To: <m2sepzfzah.fsf@HIDDEN> ("Gerd =?utf-8?Q?M=C3=B6llmann=22'?=
=?utf-8?Q?s?= message of "Fri, 03 Jan 2025 20:55:02 +0100")
References: <87jzbbke6u.fsf@HIDDEN> <m2sepzfzah.fsf@HIDDEN>
Date: Fri, 03 Jan 2025 21:34:07 +0100
Message-ID: <m2o70nfxhc.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 75322
Cc: 75322 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
>
> The pointers to string data case probably requires adding yet another
> macro SAFE_ALLOCA_FIND_A_GOOD_NAME, which, for MPS, allocates a root,
> possibly and exact one which would be good.
Or one does it as you did in b0a209e9204, that's of course also safe.
For both old and new GC. (Don't remember if you mentioned it Pip, but
old GC moves string data as well, during string compaction, should GC
run).
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at 75322) by debbugs.gnu.org; 3 Jan 2025 19:55:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 03 14:55:14 2025 Received: from localhost ([127.0.0.1]:52255 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tTnlJ-0005YV-VO for submit <at> debbugs.gnu.org; Fri, 03 Jan 2025 14:55:14 -0500 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:44209) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <gerd.moellmann@HIDDEN>) id 1tTnlH-0005U0-BE for 75322 <at> debbugs.gnu.org; Fri, 03 Jan 2025 14:55:12 -0500 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-436345cc17bso91516635e9.0 for <75322 <at> debbugs.gnu.org>; Fri, 03 Jan 2025 11:55:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735934105; x=1736538905; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=HxEOrl8vmwfS0d1lha2k0PA+ObbYy0iV2T6tz3y6Er4=; b=IVfkgiRinrQyC512XF5ljUfc53/aVmOKxzsSMdgOCliC4FYTpB30QH7iV7ncE4p2Gh v54GzJzu34JzbxxEz4Tn0Xx7OTWwUqnDMcid9xtSJS0kscJcxVXcCe5n9zvSDTXjBDIt urEXXzNdCiS+zkX5eV/pD98fSgfil+Eh2M78mUIMpvEDLqGurpIV9v5AsobEQjpWSQYy i6ptAz8KXBvTBGiE+mnr4AjELb3RT4lduwxv5a6Ciqq+T+ts6RBC8sC9u8yejJT3vBAT jBrHKmdDCvNoq15tytPDmdp26gD3FtAE86G5/EfpW4fUf54ntbrOVPbByrKKr3mnO9kb aWaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735934105; x=1736538905; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HxEOrl8vmwfS0d1lha2k0PA+ObbYy0iV2T6tz3y6Er4=; b=tn1iz1yMh7LgtHjHBRgq6RU8kS8ivr96xJFZEj2WH2Y5Cy3S5gMRrNzScKUP6fQ6n1 GCoiqRItvU3Q5B/pPpgdzsYcPnpnhbP4+XfO1ldz60GSi36XCXsCtawlA4cFZD0XMLqI s3eQD0tiThCts7hov0EC5rOumg30TEHsIxIUoVmtwaSRvEm+ygRTeOzMgpUasT+wNSaf horx3VxIDCqCsjG9uAW7jss0UjROi10PDfP2fTetKkiCSUGu4WJ65gu5wuHOMjjb1XkA ugr1FDy3uKzdv+NLccYHp7WZ02y1+wXv0YdW1A+PqS0JzaE29Sr+gUcETQQpnw63bqFk Rd1g== X-Gm-Message-State: AOJu0Yz7hE3amf51cdKht6Fe/V4ZGQcN12venpoPyBhiaE39uk481hjI mcvDcsYjpMG4H3dD39TFU1y7LHYOlyhpM+ab51Q1OSZrHxQay4HQ6ubu0w== X-Gm-Gg: ASbGncs7gbsejyu03lW72fkXZ/+XwWgHg1VSrQQMEcKiavD9DmctxxqR3vaNDRZy484 Nwai9pFBV5yr7Kd+hdHYWRiF6tT1wFN7ey+YiSTHvEzjhz93gEP+hHorio0UX5MSmZB9FCECHmm fEsgaH757S72mA6b6t0arQsWtpmlcDHg15NPr8wRfhBbIphefNXpVdGewOSSHUhTOueLI4XpKC5 5D6ir/cH2lztLPRioOXM41DptesvV1IG5qVcrDnVMK970vsAh9Ha5sr6PTklmT6ePobcqsWkZ7S e+M5nv6kjoVtAOdR4CnMZ3n9qxlT4SSGxHyoxSPD0G1wpdJud9tYWBNi33pDzZru6w== X-Google-Smtp-Source: AGHT+IF4Ipz8nvxNZvxYA42FpgI0+2AX+VMHFIBN1bvAJtkZh+49ksTA7NTJNgtrxVAmQ3zckHAplQ== X-Received: by 2002:a05:600c:510f:b0:436:1b08:4c78 with SMTP id 5b1f17b1804b1-43668b7a284mr462779605e9.31.1735934104545; Fri, 03 Jan 2025 11:55:04 -0800 (PST) Received: from pro2 (p200300e0b731ca00a950f63ba10c4b41.dip0.t-ipconnect.de. [2003:e0:b731:ca00:a950:f63b:a10c:4b41]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-43656af6c25sm524776535e9.8.2025.01.03.11.55.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jan 2025 11:55:03 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#75322: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) In-Reply-To: <87jzbbke6u.fsf@HIDDEN> (Pip Cet's message of "Fri, 03 Jan 2025 17:20:40 +0000") References: <87jzbbke6u.fsf@HIDDEN> Date: Fri, 03 Jan 2025 20:55:02 +0100 Message-ID: <m2sepzfzah.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75322 Cc: 75322 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -1.0 (-) Pip Cet <pipcet@HIDDEN> writes: > 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. I agree. One should probably check why the places storing Lisp_Objects don't use SAFE_ALLOCA_LISP. If that's possible it would work for old GC and igc. The pointers to string data case probably requires adding yet another macro SAFE_ALLOCA_FIND_A_GOOD_NAME, which, for MPS, allocates a root, possibly and exact one which would be good.
bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 3 Jan 2025 17:21:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jan 03 12:21:01 2025 Received: from localhost ([127.0.0.1]:51901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1tTlM4-000411-W8 for submit <at> debbugs.gnu.org; Fri, 03 Jan 2025 12:21:01 -0500 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 <pipcet@HIDDEN>) id 1tTlM2-00040W-IA for submit <at> debbugs.gnu.org; Fri, 03 Jan 2025 12:20:59 -0500 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 <pipcet@HIDDEN>) id 1tTlLu-0005jU-Ex for bug-gnu-emacs@HIDDEN; Fri, 03 Jan 2025 12:20:50 -0500 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 <pipcet@HIDDEN>) id 1tTlLr-0001Ek-D5 for bug-gnu-emacs@HIDDEN; 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== Date: Fri, 03 Jan 2025 17:20:40 +0000 To: bug-gnu-emacs@HIDDEN From: Pip Cet <pipcet@HIDDEN> Subject: SAFE_ALLOCA assumed to root Lisp_Objects/SSDATA(string) Message-ID: <87jzbbke6u.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: b5c5b535d19e3968222ff93fd93a963c9aff9df7 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@HIDDEN; 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-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.0 (/) 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.
Pip Cet <pipcet@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#75322; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.