Received: (at 79584) by debbugs.gnu.org; 14 Oct 2025 17:26:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 14 13:26:44 2025 Received: from localhost ([127.0.0.1]:41811 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v8inL-0001ol-7b for submit <at> debbugs.gnu.org; Tue, 14 Oct 2025 13:26:43 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52534) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1v8inH-0001o9-Mb for 79584 <at> debbugs.gnu.org; Tue, 14 Oct 2025 13:26:40 -0400 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 1v8in8-0000Ed-CD; Tue, 14 Oct 2025 13:26:31 -0400 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=yPLHHjoAm+HrVcV3MTe+2pMqKleqvalxDtTZWeUQ7H4=; b=j2eP55s/8jyS 0WcGKLRzHSeWXOUr/gaFDVD+0NHx220k6C7lt0VYTPPb1yOE6KD9SpTK4B4CP0pTOWLKgSn1c4NwP gRNuUYAv/1cPwtzLtrNwVto4WZ8G/D6mNsY+koKDuZKyRVo6dIbHdci6q8zLeI7fjI6Tpirt522P6 JyihVwxeaEHh2+Mph4HDG0KaAZFBHWXPbrkU7H1euBEpDkEFNK+RppZe+L1yUB+9R05qJjhRzZhSr 7gl+wRxaIHBv7G2FrzkuctKpUFbcw6ubK9OhXrH6wSIWOAz7HmzhCY1uSYkY+owK3ITwEOLiynCPx P+5/+B4Uu5F5Fj088lLRVg==; Date: Tue, 14 Oct 2025 20:26:25 +0300 Message-Id: <865xch2y4e.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87347lxw8t.fsf@HIDDEN> (message from Pip Cet on Tue, 14 Oct 2025 16:53:02 +0000) Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm References: <874iscb5i8.fsf_-_@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN> <m2sefoicun.fsf@HIDDEN> <871pn8yrhh.fsf@HIDDEN> <86ecr748xw.fsf@HIDDEN> <8D03D3C1-68B9-45C9-BD88-4BB59B135A2E@HIDDEN> <m24is2ject.fsf@HIDDEN> <87347lxw8t.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79584 Cc: 79584 <at> debbugs.gnu.org, oliver.reiter@HIDDEN, eller.helmut@HIDDEN, gerd.moellmann@HIDDEN, p.stephani2@HIDDEN, 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: -3.3 (---) > Date: Tue, 14 Oct 2025 16:53:02 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: Philipp Stephani <p.stephani2@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Daniel Colascione <dancol@HIDDEN>, eller.helmut@HIDDEN, oliver.reiter@HIDDEN, 79584 <at> debbugs.gnu.org > > Philipp correctly pointed out that the current API (in the non-MPS case) > works with non-stack environments. If we want to keep it, we need to > fix it for the MPS case, so initial environments which don't live on the > scanned stack will be supported. I think we should prefer keeping existing features very much. Emacs modules are mainly used by 3rd-party packages, and we don't want to break them or cause them to have 2 variants, one for the old GC and another for igc.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 14 Oct 2025 16:53:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 14 12:53:18 2025 Received: from localhost ([127.0.0.1]:41310 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v8iGz-0007Lg-OB for submit <at> debbugs.gnu.org; Tue, 14 Oct 2025 12:53:18 -0400 Received: from mail-24416.protonmail.ch ([109.224.244.16]:35679) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1v8iGv-0007KY-Dc for 79584 <at> debbugs.gnu.org; Tue, 14 Oct 2025 12:53:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1760460786; x=1760719986; bh=zLvBwespbzZn3pF9534YPPmPOCmAKrm3RZH0CSS93qY=; 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; b=y+LhInrG5y1UepAfFoaiynjL9O8yWoMyrtzs4ai1lRlmdsuQJKPwBY4j/DV1Zgk8E XUC+irGFdnubqGa+NUqOdx2WwZN8/3BdX9B0Sm8rdgS6Y3dwTccZ7Q/SJILQGoZU2g RnytI/6vfKcRHc+s0OlYiEuxCWV6CL5QvwiBl7qqETDthNuXDQY/020C2Gz0Oa/Doe u1HyJw+GHyTahZQ/Bi8B+dQWElc5vfxpM1sncO+k7VDIqTmBpGZx0BdlqtqV8l/ROk mOvA+DIhU2Ldr63up86zgjmL80+bt/B/kJj9t6qqjFMqKjPyhrA3K9u5pbl23oV5Jc n750Gp5KX5hEQ== Date: Tue, 14 Oct 2025 16:53:02 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm Message-ID: <87347lxw8t.fsf@HIDDEN> In-Reply-To: <m24is2ject.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN> <m2sefoicun.fsf@HIDDEN> <871pn8yrhh.fsf@HIDDEN> <86ecr748xw.fsf@HIDDEN> <8D03D3C1-68B9-45C9-BD88-4BB59B135A2E@HIDDEN> <m24is2ject.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 0d3579372fe1e054d4beae6f3d468cfb0f5504b8 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: 79584 Cc: 79584 <at> debbugs.gnu.org, oliver.reiter@HIDDEN, eller.helmut@HIDDEN, Philipp Stephani <p.stephani2@HIDDEN>, 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: > Philipp Stephani <p.stephani2@HIDDEN> writes: > >>>> 2. If you obtain an emacs_value elsewhere, you must treat it as a >>>> potentially GCable object. You can keep it on the stack (or in a >>>> register, which compilers give you no control over these days), but yo= u >>>> can't store it on the heap, obfuscate or munge it, serialize it, etc. >>>> If you must do so, you need to turn it into a global ref and free it >>>> when done. >> >> I believe this is a non-starter, the breakage is too drastic. The >> current guarantees about value lifetime have been in place since the >> module interface was introduced, and make it possible to use >> transparent pointer encryption, or implement modules in Go (which has >> its own GC and stacks that are invisible to MPS), etc. > > It's also not clear to me why the restrictions in (2) are spelled out in > this way. Wouldn't it suffice to just say that the emacs_values become > invalid (in the sense of don't use them any longer) when the environment > pointer goes out of scope? Which I think it already says somewhere, but > I can't find it now. That's the current status, but I fear we will eventually run into problems because freeing emacs_values is difficult. As it stands, I think it's hard to create emacs_values in a loop without running into potentially unbounded memory usage. But there were two independent proposals: GC-able emacs_values were something I wanted but which is a non-starter. Using a simple hash table rather than a pointer to a stack/registered heap location which contains a Lisp_Object is the other one. It saves about 250 LOC, improves module assertions, and removes virtually all GC assumptions from emacs-module.c. Philipp correctly pointed out that the current API (in the non-MPS case) works with non-stack environments. If we want to keep it, we need to fix it for the MPS case, so initial environments which don't live on the scanned stack will be supported. So I think it's a choice between re-implementing much of the hash table logic or using the existing hash table code. (Using vectors is, to me, a non-starter, because allocation patterns might well result in sparsely-populated huge vectors, and those are bad when represented as dense Emacs Lisp_Vectors). Pip
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 14 Oct 2025 04:29:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 14 00:29:24 2025 Received: from localhost ([127.0.0.1]:60181 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v8Wf5-00055z-Se for submit <at> debbugs.gnu.org; Tue, 14 Oct 2025 00:29:24 -0400 Received: from mail-ed1-x534.google.com ([2a00:1450:4864:20::534]:42248) 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 1v8Wey-00055a-9M for 79584 <at> debbugs.gnu.org; Tue, 14 Oct 2025 00:29:20 -0400 Received: by mail-ed1-x534.google.com with SMTP id 4fb4d7f45d1cf-631df7b2dffso2517990a12.1 for <79584 <at> debbugs.gnu.org>; Mon, 13 Oct 2025 21:29:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760416149; x=1761020949; 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=WEs6/+7DMlgl0ikjCfWPlfgO8CUdZ8Lr0uIMI8f8veQ=; b=dom1WgP0ieWscm5pQwVETTlPMubOBojHQPTJUr8QvapvNv327N7Jh6YqyQo31RCQb/ 33QPd68JayBIvKprBHlQEPO07eG87W+T/Cx/mLoF9lPYUCJQr+8pw4A8EFqClsQDJ97K jZFhb+ddZaO/5hAkL5/JlkLWNYUFfvpFHJDtBsNkX2y3jGyaUhImZ/M74FCNSxWVCBjz EJeFcWoVi3m/+5EIu0Gfot91LKaJyTqrg7S5Qic56dqvZOuISxYeFGTE8F7N16QfbSX9 LbACUm0WzD9SoehTabd/1D3PSUYbkglpmUDckXSV6AF9BNJ5VnS1wotJ24AHHb9uyO0j Gf9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760416149; x=1761020949; 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=WEs6/+7DMlgl0ikjCfWPlfgO8CUdZ8Lr0uIMI8f8veQ=; b=Amuv46Gy5A6/TZhp+rR2zuWPJUACwLeUoU/YwiVIChV8BzIcZ4Mcs9qw7WKdN4Mi5p 7jjyTmIEx4YT94qryR58ypcGU9Gk/izwQUWAiHVJ8/VTgo62sVhM22JWt2ljEWI+fstQ hhwnQoyzXWd/mMkaeWZSXWsXEtr8BT7/J7xQh3DfLLr4iK+CK1ONNyJy+5UR/9q7wCnx bY30lmJbhXi1sMpg4TUrIHvNDYnRchQuQerVTNI//3usSw+45FXtA52XzI9aXhqJtopp f91k5eZ6F0w27O1ZME31UMpb34u/+dxBHvSL/UhWVM5aPEAz6NWyJW4nspJ5yAB8xGxJ Pgzw== X-Forwarded-Encrypted: i=1; AJvYcCV3RjIMlxiSi1A79Xh6NO6mo3WHAM9k4O3w8dkM1tr7wbtmNi0LNIwajdUt6NpZaqLjh8jJtA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzqkaVY6DUhkt30+9GOzoK5xnBgEG2ajQA5w5wFJM6mJADecK7G 4+cO/DPaK4WofTpIaBFHe5kMhXa3oYPIO0VOsYnlchlZ7G3hxtoBzKOKTN840A== X-Gm-Gg: ASbGncu6XwMKmL7EOoRn+v6bIG0gEOoMJXbGQT0Y+64xEF9fQGgRDwqnAHwT7ZlOOJ3 z45UjCFCJrQxF+5r8ZTwM6Lhj/aRlAmYM7zMmJY8DYRYIIDHt+6lgudWCurgH7rqjEaQsrWp5Lf F6HGdBa1kwaeupZWGPKwj3A/voeroGt9sJspUT4pTAJeap7iJsA/bdQhgUbL3yYI9a23ZKiEOjG KLbHgQH2pg/+7LvGWjqY+z5+1ZKYtBQPzZqpDYjbA4ygrsRJDc5ypx5egXOSz1YBCTTJMWDCxmO PNHgAHdyB/8VT1EEqB61+Z5wPIdJ6zd86wSkDNbCzRjBBwsyQyn3hyIotviwJXI//BsSExnZvrm fqM8Wu6dSJFpLlbK4CDLZ1CC4uNHRls8a05QLohPp4jb8T+9Cv4QEr2IieerJSM/OluEWv1qpA8 eBwZdlkiA32kqutCkGXDMb+f1L38faI2IMoX4yogJ64HYoVOoEjg== X-Google-Smtp-Source: AGHT+IFDjW2nkGiXQZEK3I81F0Gf2GhQoo9fEhLgAwlL0EwEL3msdEYmK3FE9tx3+l6iP2jsUd8HjA== X-Received: by 2002:a05:6402:26d3:b0:639:e580:6341 with SMTP id 4fb4d7f45d1cf-639e58069b6mr20535054a12.8.1760416149121; Mon, 13 Oct 2025 21:29:09 -0700 (PDT) Received: from pro4 (p200300e0b73f3300383e209c108d6eed.dip0.t-ipconnect.de. [2003:e0:b73f:3300:383e:209c:108d:6eed]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-63a461703dbsm10396090a12.0.2025.10.13.21.29.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Oct 2025 21:29:08 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Philipp Stephani <p.stephani2@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <8D03D3C1-68B9-45C9-BD88-4BB59B135A2E@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <871pnbdhw8.fsf@HIDDEN> <877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN> <87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN> <m2sefoicun.fsf@HIDDEN> <871pn8yrhh.fsf@HIDDEN> <86ecr748xw.fsf@HIDDEN> <8D03D3C1-68B9-45C9-BD88-4BB59B135A2E@HIDDEN> Date: Tue, 14 Oct 2025 06:29:06 +0200 Message-ID: <m24is2ject.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: 79584 Cc: Pip Cet <pipcet@HIDDEN>, oliver.reiter@HIDDEN, eller.helmut@HIDDEN, 79584 <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 (-) Philipp Stephani <p.stephani2@HIDDEN> writes: >>> 2. If you obtain an emacs_value elsewhere, you must treat it as a >>> potentially GCable object. You can keep it on the stack (or in a >>> register, which compilers give you no control over these days), but you >>> can't store it on the heap, obfuscate or munge it, serialize it, etc. >>> If you must do so, you need to turn it into a global ref and free it >>> when done. > > I believe this is a non-starter, the breakage is too drastic. The > current guarantees about value lifetime have been in place since the > module interface was introduced, and make it possible to use > transparent pointer encryption, or implement modules in Go (which has > its own GC and stacks that are invisible to MPS), etc. It's also not clear to me why the restrictions in (2) are spelled out in this way. Wouldn't it suffice to just say that the emacs_values become invalid (in the sense of don't use them any longer) when the environment pointer goes out of scope? Which I think it already says somewhere, but I can't find it now.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 13 Oct 2025 17:20:35 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 13 13:20:35 2025
Received: from localhost ([127.0.0.1]:52890 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v8MDq-0004Xd-7n
for submit <at> debbugs.gnu.org; Mon, 13 Oct 2025 13:20:34 -0400
Received: from mail-wm1-x329.google.com ([2a00:1450:4864:20::329]:38125)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <p.stephani2@HIDDEN>)
id 1v8MDl-0004XE-SH
for 79584 <at> debbugs.gnu.org; Mon, 13 Oct 2025 13:20:30 -0400
Received: by mail-wm1-x329.google.com with SMTP id
5b1f17b1804b1-46e44310dbeso5145585e9.0
for <79584 <at> debbugs.gnu.org>; Mon, 13 Oct 2025 10:20:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1760376023; x=1760980823; darn=debbugs.gnu.org;
h=to:references:message-id:content-transfer-encoding:cc:date
:in-reply-to:from:subject:mime-version:from:to:cc:subject:date
:message-id:reply-to;
bh=jxkuvxXbN5E9dJDcsYhf5JDkdxNK8g671+KB99on8VQ=;
b=K8gCtndNLYCveapNVO84/RkTNNGxpDsDYPrea0wF9enWPH2I4cYen0agUsVOUnuhDK
aSqIVU68HBOv6jf6lLFPTs35F6clV1pDSRiE6K4m4V2TNdkeoKT69gGrdR2lzZOe0lvv
gS10UkOjubWcznfnTR9P25Sy2CV/DigHd/Wh9MyxHJjSyz4gi9K83OfCyLjXRbQF9ldw
D/mjRbm76zeDNvuF2RX7/xpDRKOlp2s2F8Ok0hfC76/viBLcGj4IKK6Ji65TDx00nLpS
+ZVfHBPJN/DasVOfTmA9J7D072LCy1x0IJi0v+yIwkAqs40KdlZNjMMPU//r74Z5KsIS
Sc9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1760376023; x=1760980823;
h=to:references:message-id:content-transfer-encoding:cc:date
:in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=jxkuvxXbN5E9dJDcsYhf5JDkdxNK8g671+KB99on8VQ=;
b=SQLy/HHnS3X32l+ngY6mdm/dwaykzEWe5tn9zT1MRXfD9xYfjMnbZwML6WO24Rhp6u
Gl2p3ennzjwDnonl9Xq9I2GlB+FNxBVzZ1LRMxsIRrS7iAX/SdXuUKRkn2054OwjMiIv
eAiVjsIu6JJzNK2waZ2Hq167NO7kPS7ceGWksBv0qbFSuTdM6NheedsQ/3RbVMKVWo22
6LJt8DmM/m9zZLYBSlcAi6B5iCOFbcgsrVSebB85RJ4aYKmU/T711D0/tjm8WLnHeGH4
s/NNh7d8hHAnXryJP20OO01xEWDMAslTfVDaIiGHbec9tpxt2/Q9r8be7gHHZi5E6k5X
c47w==
X-Forwarded-Encrypted: i=1;
AJvYcCWTH8nzvDqLdMkedTra0i5NpYyJY8aTajPyASMs9/gXZFmtJMai4Fz3n7wxB7MIVPJ106RfNA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxHQBzT3S2+oyXgd/OfJMTXVEsQPGMwTIBV4cteuKjnNbZ36QyI
DoXkZx+88YjxoI/F/4RA49BRBc6ezpUiSu0g86WcGnl0Hxj0AGXu80B8
X-Gm-Gg: ASbGncveigdxeppQhc6VFXVd4L99I1/5imMUokfwKXnj5JkMVV/GeXbj4e5ke+TAqXO
DJoTPXWlAXpgiqUONwp9KlM9KMxJ5TVWzxfyaqc9+XzhTo39o4+wtt9jpVZNYco8KmQ3+4tlkU8
CFg4kRmv+Iw1l2mx9g8ZB8aOnFNFFPsAmns9TSOmWqSo6Gxvd2Jgnzgpgq1De9d0B1rK0N8X5eL
1ng591g99bEdmyTPuuuBnC1lXy4XX/AnrS9B5vbOOz54ELs5O6YbtQ+YmA7tuMYnXObiAcKqNFB
f7ac/WlVNBS10L186yEh6qfGPo1m8np+JanFhysjPgLFpADtyiPy4HVFL253w72Ybmu8SZKsYF8
r/wqQgQ5C8dA0HD531ztHKYXNaEAuBSKaopUOCT4zl5q45cRkwA+LmsQ8LlENseUr5viun4ujx3
E=
X-Google-Smtp-Source: AGHT+IFquyKOjxxCPU3qkyJBhsXUmDpPGfdDrHYAfhM+PBotaRppvVZJLhZ6K1Fx/dEFEHQNtq5C8g==
X-Received: by 2002:a05:600c:1e85:b0:46e:43f0:6181 with SMTP id
5b1f17b1804b1-46fa9b17dc8mr89162795e9.7.1760376023233;
Mon, 13 Oct 2025 10:20:23 -0700 (PDT)
Received: from smtpclient.apple ([2001:a61:3a9a:e01:7939:2077:7a9b:b5dc])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-46fab3cc939sm135291165e9.1.2025.10.13.10.20.21
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Mon, 13 Oct 2025 10:20:22 -0700 (PDT)
Content-Type: text/plain;
charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.100.1.1.5\))
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
From: Philipp Stephani <p.stephani2@HIDDEN>
In-Reply-To: <86ecr748xw.fsf@HIDDEN>
Date: Mon, 13 Oct 2025 19:20:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D03D3C1-68B9-45C9-BD88-4BB59B135A2E@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <871pnbdhw8.fsf@HIDDEN>
<877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN>
<87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN>
<87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN>
<m2sefoicun.fsf@HIDDEN> <871pn8yrhh.fsf@HIDDEN>
<86ecr748xw.fsf@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
X-Mailer: Apple Mail (2.3864.100.1.1.5)
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 79584
Cc: Pip Cet <pipcet@HIDDEN>, oliver.reiter@HIDDEN,
eller.helmut@HIDDEN, 79584 <at> debbugs.gnu.org, gerd.moellmann@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.7 (/)
> Am 13.10.2025 um 08:22 schrieb Eli Zaretskii <eliz@HIDDEN>:
>=20
>> Date: Sun, 12 Oct 2025 17:13:43 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: Helmut Eller <eller.helmut@HIDDEN>, Eli Zaretskii =
<eliz@HIDDEN>, oliver.reiter@HIDDEN, 79584 <at> debbugs.gnu.org
>=20
> Since we are discussing various design changes for emacs modules, I
> think we should bring Daniel and Philipp on-board of the discussion.
>=20
> Daniel and Philipp, any comments or suggestions on the issues
> discussed in this thread?
Thanks. It seems the proposal would be a pretty big breaking change to =
the documented behavior of the module interface. I don't think we =
should make such a change (but see below for an alternative that I hope =
works).
>=20
>>=20
>> So my proposal is to give up as far as possible on immovable objects =
and
>> huge ambiguous roots, whether on the stack or the heap.
>>=20
>> Here's my idea:
>>=20
>> An emacs_value is a hash index (if we want to keep it a pointer, we =
can
>> either cast an integer to a pointer or make it a pointer to an =
integer
>> on the heap somewhere, or assume LISP_WORDS_ARE_POINTERS and simply =
cast
>> a fixnum to emacs_value).
The only requirements for emacs_value are:
- On the API level, emacs_value objects are pointers to some undefined =
struct.
- On the ABI level, they are pointer-sized.
- While they are live, they remain stable and uniquely refer to a Lisp =
value.
- They remain live until the environment they live in goes out of scope =
(except for the global references).
So changing their value into an integer (cast to a pointer) is no =
problem, as long as the integer fits into a uintptr_t.
In other words, you can rewrite lisp_to_value as
emacs_value lisp_to_value(emacs_env *env, Lisp_Object lisp) {
// calculate <thing>
return (emacs_value) (void *) (uintptr_t) <thing>
}
and that should be OK as long as <thing> fits into an uintptr_t (or =
intptr_t), stably identifies `lisp', and remains valid for the lifetime =
of `env'.
I don't understand the comment about LISP_WORDS_ARE_POINTERS, that =
should be entirely unrelated.
>> If the index is positive, the object is
>> global, and has to be recycled explicitly. If the index is negative, =
the
>> object can go away as soon as the environment it's in dies; in =
practice,
>> I believe it's probably sufficient to recycle such objects once the =
last
>> local environment goes out of scope, and only if there are too many =
such
>> references or debugging is enabled.
>>=20
>> No immovable objects. No refcounting. A simple single index-to-object
>> hash table, which gets rebuilt (and thus shrunk) when it's convenient
>> (all module environments went out of scope).
That would leak a lot of local references, and seems unnecessarily =
complicated. There shouldn't be a need for a hashtable for local =
values, because their lifetimes are trivial: you just need to ensure to =
free them once their environment goes out of scope (in other words, the =
environment serves as an arena). It should be sufficient to allocate a =
per-thread array (in struct thread_state) and push/pop emacs_values from =
there since module functions within a single thread can't have =
non-nested lifetimes. You could then e.g. use the upper 32 bits of an =
emacs_value as a thread index (storing the mapping from thread indices =
to thread_states in a hashtable) and the lower 32 bits as index into the =
per-thread stack. You'd then mark all per-thread stacks as exact GC =
roots. I think that way you can move around the underlying Lisp_Objects =
as you want, as long as the indices remain stable. You'd need some =
special-casing for globals (using a hash-table as described), and the =
static values to be returned in an OOM situation, but those can just be =
special thread indices that are not otherwise used.
>>=20
>> If there are problems with long-lived module environments (or =
multiple
>> independent module environments making it so we never reach the "all
>> module environments are dead" point), we can deal with that
>> complication. Let's burn that bridge when we come to it.
Right now local value allocation is precise, i.e. values are immediately =
freed once they go out of scope. Since their lifetime is always bound =
by the environment lifetime, that makes the allocation approach pretty =
trivial, without the need for a GC. Why make this more complicated than =
now?
I can see that you don't want immovable objects or ambiguous references, =
so using indices instead of true pointers for emacs_value makes sense. =
But I don't think we should (or need to) break the module contract for =
that.
>>=20
>> Plenty of silly possible optimizations, of course, but do we need to
>> deal with those? I suspect not.
>>=20
>> But just to be on the sure side, let's modify the documented module =
API
>> in this way:
>>=20
>> 1. If you obtain an emacs_value from module_make_global_ref, you can =
do
>> with it what you want: it can live in registers, on the stack, on the
>> heap, and you can even serialize it (send it over the network or save =
it
>> to disk) and unserialize it back to an emacs_value if you must for =
some
>> reason do so. But you must free it when done or it's Emacs (not your
>> module) which leaks valuable memory and slows down other modules.
That's the current state.
>>=20
>> 2. If you obtain an emacs_value elsewhere, you must treat it as a
>> potentially GCable object. You can keep it on the stack (or in a
>> register, which compilers give you no control over these days), but =
you
>> can't store it on the heap, obfuscate or munge it, serialize it, etc.
>> If you must do so, you need to turn it into a global ref and free it
>> when done.
I believe this is a non-starter, the breakage is too drastic. The =
current guarantees about value lifetime have been in place since the =
module interface was introduced, and make it possible to use transparent =
pointer encryption, or implement modules in Go (which has its own GC and =
stacks that are invisible to MPS), etc.
>>=20
>> 3. There is no guarantee that identical objects have identical
>> emacs_values, not even if you try to create the same global ref =
twice.
>>=20
>> 4. While emacs_value will usually "look like" a pointer, we make no
>> guarantees about its alignedness, tag bits, or anything else.
These two are also the current state already; no change needed.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 13 Oct 2025 17:20:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 13 13:20:34 2025
Received: from localhost ([127.0.0.1]:52888 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v8MDp-0004XY-GL
for submit <at> debbugs.gnu.org; Mon, 13 Oct 2025 13:20:34 -0400
Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:38436)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <p.stephani2@HIDDEN>)
id 1v8MDl-0004XC-Gs
for 79584 <at> debbugs.gnu.org; Mon, 13 Oct 2025 13:20:30 -0400
Received: by mail-wm1-x32d.google.com with SMTP id
5b1f17b1804b1-46e38c21fafso8319765e9.2
for <79584 <at> debbugs.gnu.org>; Mon, 13 Oct 2025 10:20:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1760376023; x=1760980823; darn=debbugs.gnu.org;
h=to:references:message-id:content-transfer-encoding:cc:date
:in-reply-to:from:subject:mime-version:from:to:cc:subject:date
:message-id:reply-to;
bh=jxkuvxXbN5E9dJDcsYhf5JDkdxNK8g671+KB99on8VQ=;
b=K8gCtndNLYCveapNVO84/RkTNNGxpDsDYPrea0wF9enWPH2I4cYen0agUsVOUnuhDK
aSqIVU68HBOv6jf6lLFPTs35F6clV1pDSRiE6K4m4V2TNdkeoKT69gGrdR2lzZOe0lvv
gS10UkOjubWcznfnTR9P25Sy2CV/DigHd/Wh9MyxHJjSyz4gi9K83OfCyLjXRbQF9ldw
D/mjRbm76zeDNvuF2RX7/xpDRKOlp2s2F8Ok0hfC76/viBLcGj4IKK6Ji65TDx00nLpS
+ZVfHBPJN/DasVOfTmA9J7D072LCy1x0IJi0v+yIwkAqs40KdlZNjMMPU//r74Z5KsIS
Sc9Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1760376023; x=1760980823;
h=to:references:message-id:content-transfer-encoding:cc:date
:in-reply-to:from:subject:mime-version:x-gm-message-state:from:to:cc
:subject:date:message-id:reply-to;
bh=jxkuvxXbN5E9dJDcsYhf5JDkdxNK8g671+KB99on8VQ=;
b=RM1pjkcAOR+JXlYbYxGZGpeKsPyArZDCsg0pCkZP7nyIH3CRPU5l9PsuhO1OmlezkY
vzI/+zNslFr3S/OWw7V3UbzKvcNfGooyRunsI5ByYaF49aW9gtRp1Nsuyawrs1WDJA/x
0sxtar9457/XxWcSFaoJ8cfEHnab+D5EeMYG0U7jRvYi8GZVfYz+e/x1c/antzez6SuQ
3hbbz3Ii2P0ST/CbPHJk/XECBLbgMnVSQezdi+lU+vINA764al//TaWVm1TRVlcIX+tv
s5678TS4hH9FNecIHva8MzuBtBmPSkJV5nNPJMQWDLjt6s3iWPc1S9KhTnv4u8SGv9Xu
IAKQ==
X-Forwarded-Encrypted: i=1;
AJvYcCUUz8jvFv5eZ/BE+Bygg9DorFg8fWFipY3cvec/zFOnGwdIUyF4E/93OOFNXKfHK1SqTHnsdQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxLsG4jSD3NayBwPGfNEKu0XiMWI2fUj31KQCd0lwzdccQkQRo9
VJ0Wvcqn7ldvUSYYONa7QL3Co7xCq/DrFa/n8BrJ0TLpWZjOgwWcZv9GYplXkQ==
X-Gm-Gg: ASbGncs4gbfqrWikqd9b94pjRnILzLrB7MCLcdBI6xH9Z53+/sxxytafDMRIBjZATBi
vwHiejP1jAgMnavzSXcNYNcBgR6ZhR9GPGv1yiRRevWNUF32cN9JX9M84C212br0dex/55B2V9L
SXuOfRVVKnOsXICsbgTsDIvEZ6ZO6sdcKmBteFeBe3klXecFPgwMquapVbtA3ylj09EhHQx8jDk
CQNmqXrM1IMtytJTiM6poLgwiJMJ+NT6CvsvURCiu8ZIx7M+O5FqyOOygCnmbx0rvcuyLu28BRp
mrHg/pNVpD2pKAmb62/Ql7Z8eYN2xJkj5jtZoNi3TvZYR+3+zE0clyXLUmfSaaoEKK19PlqGm+h
82bxxpKts6ovVjMLvyx5Py9j16OW0jKreC8tz5LF/vRkalyxgUtO4HNOreYTrrpdmi0+WcYE9FV
F8S5UvnNtx+HRu+LMFG7Ye
X-Google-Smtp-Source: AGHT+IEIgzzspkaAWDfi4Nc5Ss0tzcAuZjFBj3IjlZyptzgQjClWEGDW7HxMnQyAx8gnope8pFYRFA==
X-Received: by 2002:a05:600c:4fc1:b0:46e:4a2b:d34c with SMTP id
5b1f17b1804b1-46fa9b08a04mr88344075e9.6.1760376022835;
Mon, 13 Oct 2025 10:20:22 -0700 (PDT)
Received: from smtpclient.apple ([2001:a61:3a9a:e01:7939:2077:7a9b:b5dc])
by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-426ce5cf71dsm18650819f8f.29.2025.10.13.10.20.21
(version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128);
Mon, 13 Oct 2025 10:20:22 -0700 (PDT)
Content-Type: text/plain;
charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3864.100.1.1.5\))
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
From: Philipp Stephani <p.stephani2@HIDDEN>
In-Reply-To: <86ecr748xw.fsf@HIDDEN>
Date: Mon, 13 Oct 2025 19:20:10 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <8D03D3C1-68B9-45C9-BD88-4BB59B135A2E@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <871pnbdhw8.fsf@HIDDEN>
<877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN>
<87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN>
<87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN>
<m2sefoicun.fsf@HIDDEN> <871pn8yrhh.fsf@HIDDEN>
<86ecr748xw.fsf@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
X-Mailer: Apple Mail (2.3864.100.1.1.5)
X-Spam-Score: 0.3 (/)
X-Debbugs-Envelope-To: 79584
Cc: Pip Cet <pipcet@HIDDEN>, oliver.reiter@HIDDEN,
eller.helmut@HIDDEN, 79584 <at> debbugs.gnu.org, gerd.moellmann@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.7 (/)
> Am 13.10.2025 um 08:22 schrieb Eli Zaretskii <eliz@HIDDEN>:
>=20
>> Date: Sun, 12 Oct 2025 17:13:43 +0000
>> From: Pip Cet <pipcet@HIDDEN>
>> Cc: Helmut Eller <eller.helmut@HIDDEN>, Eli Zaretskii =
<eliz@HIDDEN>, oliver.reiter@HIDDEN, 79584 <at> debbugs.gnu.org
>=20
> Since we are discussing various design changes for emacs modules, I
> think we should bring Daniel and Philipp on-board of the discussion.
>=20
> Daniel and Philipp, any comments or suggestions on the issues
> discussed in this thread?
Thanks. It seems the proposal would be a pretty big breaking change to =
the documented behavior of the module interface. I don't think we =
should make such a change (but see below for an alternative that I hope =
works).
>=20
>>=20
>> So my proposal is to give up as far as possible on immovable objects =
and
>> huge ambiguous roots, whether on the stack or the heap.
>>=20
>> Here's my idea:
>>=20
>> An emacs_value is a hash index (if we want to keep it a pointer, we =
can
>> either cast an integer to a pointer or make it a pointer to an =
integer
>> on the heap somewhere, or assume LISP_WORDS_ARE_POINTERS and simply =
cast
>> a fixnum to emacs_value).
The only requirements for emacs_value are:
- On the API level, emacs_value objects are pointers to some undefined =
struct.
- On the ABI level, they are pointer-sized.
- While they are live, they remain stable and uniquely refer to a Lisp =
value.
- They remain live until the environment they live in goes out of scope =
(except for the global references).
So changing their value into an integer (cast to a pointer) is no =
problem, as long as the integer fits into a uintptr_t.
In other words, you can rewrite lisp_to_value as
emacs_value lisp_to_value(emacs_env *env, Lisp_Object lisp) {
// calculate <thing>
return (emacs_value) (void *) (uintptr_t) <thing>
}
and that should be OK as long as <thing> fits into an uintptr_t (or =
intptr_t), stably identifies `lisp', and remains valid for the lifetime =
of `env'.
I don't understand the comment about LISP_WORDS_ARE_POINTERS, that =
should be entirely unrelated.
>> If the index is positive, the object is
>> global, and has to be recycled explicitly. If the index is negative, =
the
>> object can go away as soon as the environment it's in dies; in =
practice,
>> I believe it's probably sufficient to recycle such objects once the =
last
>> local environment goes out of scope, and only if there are too many =
such
>> references or debugging is enabled.
>>=20
>> No immovable objects. No refcounting. A simple single index-to-object
>> hash table, which gets rebuilt (and thus shrunk) when it's convenient
>> (all module environments went out of scope).
That would leak a lot of local references, and seems unnecessarily =
complicated. There shouldn't be a need for a hashtable for local =
values, because their lifetimes are trivial: you just need to ensure to =
free them once their environment goes out of scope (in other words, the =
environment serves as an arena). It should be sufficient to allocate a =
per-thread array (in struct thread_state) and push/pop emacs_values from =
there since module functions within a single thread can't have =
non-nested lifetimes. You could then e.g. use the upper 32 bits of an =
emacs_value as a thread index (storing the mapping from thread indices =
to thread_states in a hashtable) and the lower 32 bits as index into the =
per-thread stack. You'd then mark all per-thread stacks as exact GC =
roots. I think that way you can move around the underlying Lisp_Objects =
as you want, as long as the indices remain stable. You'd need some =
special-casing for globals (using a hash-table as described), and the =
static values to be returned in an OOM situation, but those can just be =
special thread indices that are not otherwise used.
>>=20
>> If there are problems with long-lived module environments (or =
multiple
>> independent module environments making it so we never reach the "all
>> module environments are dead" point), we can deal with that
>> complication. Let's burn that bridge when we come to it.
Right now local value allocation is precise, i.e. values are immediately =
freed once they go out of scope. Since their lifetime is always bound =
by the environment lifetime, that makes the allocation approach pretty =
trivial, without the need for a GC. Why make this more complicated than =
now?
I can see that you don't want immovable objects or ambiguous references, =
so using indices instead of true pointers for emacs_value makes sense. =
But I don't think we should (or need to) break the module contract for =
that.
>>=20
>> Plenty of silly possible optimizations, of course, but do we need to
>> deal with those? I suspect not.
>>=20
>> But just to be on the sure side, let's modify the documented module =
API
>> in this way:
>>=20
>> 1. If you obtain an emacs_value from module_make_global_ref, you can =
do
>> with it what you want: it can live in registers, on the stack, on the
>> heap, and you can even serialize it (send it over the network or save =
it
>> to disk) and unserialize it back to an emacs_value if you must for =
some
>> reason do so. But you must free it when done or it's Emacs (not your
>> module) which leaks valuable memory and slows down other modules.
That's the current state.
>>=20
>> 2. If you obtain an emacs_value elsewhere, you must treat it as a
>> potentially GCable object. You can keep it on the stack (or in a
>> register, which compilers give you no control over these days), but =
you
>> can't store it on the heap, obfuscate or munge it, serialize it, etc.
>> If you must do so, you need to turn it into a global ref and free it
>> when done.
I believe this is a non-starter, the breakage is too drastic. The =
current guarantees about value lifetime have been in place since the =
module interface was introduced, and make it possible to use transparent =
pointer encryption, or implement modules in Go (which has its own GC and =
stacks that are invisible to MPS), etc.
>>=20
>> 3. There is no guarantee that identical objects have identical
>> emacs_values, not even if you try to create the same global ref =
twice.
>>=20
>> 4. While emacs_value will usually "look like" a pointer, we make no
>> guarantees about its alignedness, tag bits, or anything else.
These two are also the current state already; no change needed.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 13 Oct 2025 17:00:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 13 13:00:07 2025 Received: from localhost ([127.0.0.1]:52838 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v8Lu2-0003OO-RK for submit <at> debbugs.gnu.org; Mon, 13 Oct 2025 13:00:07 -0400 Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:58381) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>) id 1v8Lu0-0003NB-1V for 79584 <at> debbugs.gnu.org; Mon, 13 Oct 2025 13:00:04 -0400 Received: by mail-wm1-x32e.google.com with SMTP id 5b1f17b1804b1-46fc5e54cceso8735245e9.0 for <79584 <at> debbugs.gnu.org>; Mon, 13 Oct 2025 10:00:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760374796; x=1760979596; 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=YTn88HUTUTRLJGLPS9nM+YHB651ZXZyduTn4J+Rh/O0=; b=F6jc4+x5OVJnOH+7A7Udl1UkZfUZ12rFtib9ZV/pzpcniAAACKoybIrh2pzqhZzgr8 bj8+3nlmS5HMIcCiuQVOU571kO1dk3R5/ffVavQKNQflCB3LnBBG5Hgmobp/DJbGs+si dSA7s59epCfoLIj0mnnpN/9c9ItZYKgkjeD2W6E+7c4jFS1s8yjzmoCnJFs8yi35eN18 5hNBzldluagui6uNommXyHvp67Vy2juwDoBHTv/5T3z7GyCrzPMFgOfv37rIroPqc1RE uisZG4v8wONj4dp5AXbEPos4NqOjt8ECcTwAApwkO5FfXZtKWaJIhGjcQ7cYVmd19pSO bYbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760374796; x=1760979596; 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=YTn88HUTUTRLJGLPS9nM+YHB651ZXZyduTn4J+Rh/O0=; b=M8YjHB5UGsK+78FMN03ccKMcatVcgWnQxyoRUI7HPOJfbnlrMRGX8Jk7L9vdpEqtHj SpdDp8uH/dU/Kdmzv/AMsKRG+RIwJsiB8voa5f9DI+j/t04O4lhxFbE1GBS5rDOrayVD 2tLnh2ghUA1gvC5wsIlxmi5R8m82PNPNdCyE3cGiDG0NUcCYLXWbiJXvkZBbs2MtyhmF s0MxTlRRbBSneLiDERgIOg9e2WHxqcYgWrqBLWXumImRI8pFx27QEKqW0ddo9gn+Y7fD SfVTfzcw2yBtucNeWdEyn2nHuLb5OMeeTl7YbhLXYAQynPbZhzdWLSQSKNfqXo6krWei 2PcA== X-Forwarded-Encrypted: i=1; AJvYcCVNMQZowTP+CQM4Akyhu9KKSTAYr3i0APjAkcV6nnJUgos/ZrumQp+r4HMg/E24N8Kubo9Fow==@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywd1CN28stiOZXQsXoaWG/16j9fOC/XaxFpsx3T1Vjx4kesonXt ZYoTaM7xUMSTKBrA9FTyaKR97iQS0PieuH5zFWD6rD2w8lFhTD1QeoH+QdWc+w== X-Gm-Gg: ASbGncuQiFCPo5as7CtujILXdeKQ/ltQy5uhiZZIx/QVjhoTMadM1krFbFVIdm9c/Vu fv7Ij+fbeow2iRMOxZDCr5S1psFaUQHPt8cpOAATC/7cOgma5wSPXjI1oWEjoLkIvS+F5/uRMtw MLkyeNGkKU95ORZ1U9/Nsyo2lPGc5GMb5Fsn0CXIjbH/c81l4b1fpHFTDszUd6JbY1gBnEc/AEZ bNXclQx3lwkyYnAmjA9RCZJyRnaCXFityXr8gsnK8+V/1Kwc9XFabY7qlt0Y0apndaWlceSGIrE EWYv1s1roA07AXpJSDnoNyVUb2ncuVKEFXZzAzx8A/qxdUQyjLk7GrJLlTf9XdIity0ZNI/Lcan oVUzf5MqyWinr3tkQ/1uuC7Xr/uzVCmpJGf+fUew= X-Google-Smtp-Source: AGHT+IHSrkg6g5GgW4YkDcX+e83jElh35esOyW015KhpaksvyLehAcFvfVhaSdZGlf4ggXnXV0XmCA== X-Received: by 2002:a05:600c:8409:b0:46e:442c:f5e1 with SMTP id 5b1f17b1804b1-46fa9b1a048mr159582785e9.35.1760374796325; Mon, 13 Oct 2025 09:59:56 -0700 (PDT) Received: from caladan ([31.177.112.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-46fb4982b25sm195629605e9.7.2025.10.13.09.59.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Oct 2025 09:59:56 -0700 (PDT) From: Helmut Eller <eller.helmut@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <87h5w3xz61.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN> <m2sefoicun.fsf@HIDDEN> <871pn8yrhh.fsf@HIDDEN> <m2o6qchs9e.fsf@HIDDEN> <87sefnylcc.fsf@HIDDEN> <m2qzv7nbo9.fsf@HIDDEN> <87h5w3xz61.fsf@HIDDEN> Date: Mon, 13 Oct 2025 18:59:55 +0200 Message-ID: <87bjma7n5g.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: 79584 Cc: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, oliver.reiter@HIDDEN, 79584 <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 Mon, Oct 13 2025, Pip Cet wrote: > So make 'bc' a pointer to non-MPS-managed memory, which we can access > freely from the scanning function? Yes; please commit it. Helmut
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 13 Oct 2025 16:01:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 13 12:01:54 2025
Received: from localhost ([127.0.0.1]:52621 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v8Kzh-0008VG-UM
for submit <at> debbugs.gnu.org; Mon, 13 Oct 2025 12:01:54 -0400
Received: from dancol.org ([2600:3c01:e000:3d8::1]:60172)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1v8Kzd-0008V2-Pg
for 79584 <at> debbugs.gnu.org; Mon, 13 Oct 2025 12:01:51 -0400
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=zz4pbukq1FlRCUyFBLW/tAwFYM45JqcHxLHN6dbrGwc=; b=Jg+9YywOib/eZIZZN5SXVlnn7U
P8l9nvLd4DoPynjYvtvPZUJIBgCxTUQussWLpg1Ml451ngiDDbtXNaAUipFkil6oARaahkKdHc3Jy
8l4AZ5/FJpJQHIb2OuLNr19hRVQIBoVONP4nnRZhpLMtbg+mNosoWFuhF7nOiw+zzSBGlim440QZy
7k0B7y+b2Uf0q5oVe5ZxUA5/rz1Z2g2ByKkenE3Fb5yjW37xFMMV04Q4qavjQTPN95MdACnQ52UZ1
mT433yYCBPSZP+Xn9ajtQ8zVT8NgNESU9TKC7AJ5ZNCfQCJlfnij/ZWiGgZrt3RQ73iGKK3Z9vQ/t
djKqLmFg==;
Received: from [2600:1010:b00b:eee4:0:3:e35a:d701] (port=54280
helo=ehlo.thunderbird.net)
by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
(Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1v8Kwd-003nGL-1p;
Mon, 13 Oct 2025 11:58:43 -0400
Date: Mon, 13 Oct 2025 09:01:30 -0700
From: Daniel Colascione <dancol@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
User-Agent: K-9 Mail for Android
In-Reply-To: <87bjmayg8z.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <87347rxo57.fsf@HIDDEN>
<m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN>
<m2wm50ig2j.fsf@HIDDEN> <m2sefoicun.fsf@HIDDEN>
<871pn8yrhh.fsf@HIDDEN> <86ecr748xw.fsf@HIDDEN>
<8FACC7A1-F7E1-47E9-AC12-9CB1CA89582D@HIDDEN>
<87bjmayg8z.fsf@HIDDEN>
Message-ID: <D6E07016-A3FE-4CA8-B415-73DEF0257297@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: 79584
Cc: 79584 <at> debbugs.gnu.org, oliver.reiter@HIDDEN, eller.helmut@HIDDEN,
gerd.moellmann@HIDDEN, Philipp Stephani <p.stephani2@HIDDEN>,
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 (-)
On October 13, 2025 8:28:42 AM PDT, Pip Cet <pipcet@protonmail=2Ecom> wrote=
:
>"Daniel Colascione" <dancol@dancol=2Eorg> writes:
>
>> On October 12, 2025 11:22:51 PM PDT, Eli Zaretskii <eliz@gnu=2Eorg> wro=
te:
>>>> Date: Sun, 12 Oct 2025 17:13:43 +0000
>>>> From: Pip Cet <pipcet@protonmail=2Ecom>
>>>> Cc: Helmut Eller <eller=2Ehelmut@gmail=2Ecom>, Eli Zaretskii <eliz@gn=
u=2Eorg>, oliver=2Ereiter@snapdragon=2Ecc, 79584@debbugs=2Egnu=2Eorg
>>>
>>>Since we are discussing various design changes for emacs modules, I
>>>think we should bring Daniel and Philipp on-board of the discussion=2E
>
>Thanks!
>
>I fear I'm a little confused here: the code I'm proposing lets you do
>whatever you want with an emacs_value: when the last environment goes
>out of scope, we consider whether to collect the negatively-indexed hash
>entries=2E
>
>The API documentation change I'm proposing would make it easier for
>future code to overcome this limitation, should that become necessary,
>by limiting what you can validly do with an emacs_value (which depends
>on whether it was a global reference or not)=2E
>
>>>Daniel and Philipp, any comments or suggestions on the issues
>>>discussed in this thread?
>>>
>>>> Gerd M=C3=B6llmann <gerd=2Emoellmann@gmail=2Ecom> writes:
>>>>
>>>> > Gerd M=C3=B6llmann <gerd=2Emoellmann@gmail=2Ecom> writes:
>>>> >
>>>> >> Pip Cet <pipcet@protonmail=2Ecom> writes:
>>>> >>
>>>> >>> Gerd M=C3=B6llmann <gerd=2Emoellmann@gmail=2Ecom> writes:
>>>> >>>
>>>> >>>> Helmut Eller <eller=2Ehelmut@gmail=2Ecom> writes:
>>>> >>>>
>>>> >>>>> On Thu, Oct 09 2025, Gerd M=C3=B6llmann wrote:
>>>> >>>>>
>>>> >>>>>>> It would mean that all objects referenced by the AMS pool are=
pinned=2E
>>>> >>>>>>> Which could be useful=2E
>>>> >>>>>>
>>>> >>>>>> Who makes sure that objects in AMS get scanned and pin referen=
ced
>>>> >>>>>> objects? How does MPS detect when references in AMS objects ch=
ange when
>>>> >>>>>> there are no barriers? Ans so on=2E
>>>> >>>>>
>>>> >>>>> It looks like it's not implemented=2E I added the MPS_KEY_RANK=
argument,
>>>> >>>>> but then (require 'vterm) triggers this assertion:
>>>> >>>>>
>>>> >>>>> #5 traceFindGrey (segReturn=3D<synthetic pointer>,
>>>> >>>>> rankReturn=3D<synthetic pointer>, arena=3D0x7ffff7fbe000, t=
i=3D0)
>>>> >>>>> at =2E=2E/mps/code/trace=2Ec:1103
>>>> >>>>> 1103 AVER(RingIsSingle(ArenaGreyRing(arena, RankAMBIG)));
>>>> >>>>>
>>>> >>>>> Disappointing=2E
>>>> >>>>
>>>> >>>> Please find attached the "final" version of what I have in my Em=
acs,
>>>> >>>> ported to feature/igc=2E No further gymnastics needed for module=
s=2E I'd
>>>> >>>> like to apply that, okay with you?
>>>> >>>
>>>> >>> Does this work with the PVEC_THREAD allocation? The reason for us=
ing
>>>> >>> alloc_immovable there was to avoid barriers, and now we're alloca=
ting
>>>> >>> from a pool which does have barriers=2E
>>>> >>>
>>>> >>
>>>> >> It works on macOS at least, AFAICT, but I also don't remember 1 bi=
t
>>>> >> about that subject, so maybe it doesn't work on other systems?
>>>> >
>>>> > Looking at thread_state, I see, as one would expect, it has Lisp_Ob=
ject
>>>> > members=2E When one of these objects moves in memory, these referen=
ces
>>>> > must be updated=2E So far so good and normal=2E
>>>> >
>>>> > How does this updating of references work, if thread_state does not=
have
>>>> > barriers?
>>>>
>>>> I'm very confused now, having run some experiments=2E The behavior I'=
m
>>>> observing is this:
>>>>
>>>> * when a trace starts, the AMS segments are unprotected=2E That's oka=
y,
>>>> because MPS knows they're not reachable directly from the roots (al=
l
>>>> reachability paths go through a barriered segment)
>>>> * symbols move, but the AMS segment remains unprotected=2E
>>>> * when you look at the AMC segment containing the Vmodule_refs_hash h=
ash
>>>> table, MPS protects the AMS segment (????)
>>>> * when you access the AMS segment afterwards, you hit the barrier and
>>>> the reference gets fixed before you use it=2E
>>>>
>>>> I think this is rather confusing, particularly the step labelled (???=
?)=2E
>>>> AMS is documented not to have barriers, but AMSSeg inherits from
>>>> MutatorSeg, which installs barriers (as observed) when the segment
>>>> becomes grey=2E
>>>>
>>>> Our problem, whether or not barriers are used, is that we accessed a
>>>> segment that was considered white, and I don't think that's okay whet=
her
>>>> you're talking about AMS or AMC=2E
>>>>
>>>> I think=2E
>>>>
>>>> > My answer is that it can't, and if AMS hadn't falsely claimed
>>>> > to work with references to other pools, that would have been obviou=
s
>>>> > from the start=2E
>>>>
>>>> AMS works with references to other pools to the same extent that AMC
>>>> does, AFAIU=2E You can't stash away a pointer to what used to be a va=
lid
>>>> object in either pool, then dereference it, unless you tell MPS about
>>>> the pointer first=2E
>>>>
>>>> But the other limitations of AMS make it a bad choice: we need ambigu=
ous
>>>> interior pointers keeping objects alive=2E
>>>>
>>>> So my proposal is to give up as far as possible on immovable objects =
and
>>>> huge ambiguous roots, whether on the stack or the heap=2E
>>>>
>>>> Here's my idea:
>>>>
>>>> An emacs_value is a hash index (if we want to keep it a pointer, we c=
an
>>>> either cast an integer to a pointer or make it a pointer to an intege=
r
>>>> on the heap somewhere, or assume LISP_WORDS_ARE_POINTERS and simply c=
ast
>>>> a fixnum to emacs_value)=2E If the index is positive, the object is
>>>> global, and has to be recycled explicitly=2E If the index is negative=
, the
>>>> object can go away as soon as the environment it's in dies; in practi=
ce,
>>>> I believe it's probably sufficient to recycle such objects once the l=
ast
>>>> local environment goes out of scope, and only if there are too many s=
uch
>>>> references or debugging is enabled=2E
>>>>
>>>> No immovable objects=2E No refcounting=2E A simple single index-to-ob=
ject
>>>> hash table, which gets rebuilt (and thus shrunk) when it's convenient
>>>> (all module environments went out of scope)=2E
>>>>
>>>> If there are problems with long-lived module environments (or multipl=
e
>>>> independent module environments making it so we never reach the "all
>>>> module environments are dead" point), we can deal with that
>>>> complication=2E Let's burn that bridge when we come to it=2E
>>>>
>>>> Plenty of silly possible optimizations, of course, but do we need to
>>>> deal with those? I suspect not=2E
>>>>
>>>> But just to be on the sure side, let's modify the documented module A=
PI
>>>> in this way:
>>>>
>>>> 1=2E If you obtain an emacs_value from module_make_global_ref, you ca=
n do
>>>> with it what you want: it can live in registers, on the stack, on the
>>>> heap, and you can even serialize it (send it over the network or save=
it
>>>> to disk) and unserialize it back to an emacs_value if you must for so=
me
>>>> reason do so=2E But you must free it when done or it's Emacs (not you=
r
>>>> module) which leaks valuable memory and slows down other modules=2E
>>>>
>>>> 2=2E If you obtain an emacs_value elsewhere, you must treat it as a
>>>> potentially GCable object=2E You can keep it on the stack (or in a
>>>> register, which compilers give you no control over these days), but y=
ou
>>>> can't store it on the heap, obfuscate or munge it, serialize it, etc=
=2E
>>>> If you must do so, you need to turn it into a global ref and free it
>>>> when done=2E
>>
>> Let's be a bit more precise about the requirement: you can put one of
>> these values on the heap or do whatever you want with it, but its
>> value lifetime extends only so long as a GC scan of the stack and
>> registers can find it, and (IIUC) this scan can happen any
>> time=2E Correct? Compilers can and do occasionally tear values when the=
y
>> think nobody's looking=2E
>
>I think "make sure one copy is on the stack, but it won't be modified
>there so you can use another copy which is more convenient" is a useful,
>and necessary, addition to the API proposal! Thanks!
>
>IOW, things like
>
>function()
>{
> {
> emacs_value v =3D =2E=2E=2E;
> memcpy (alloca (sizeof v), &v, sizeof v);
> <=2E=2E=2E put a copy of v on the heap =2E=2E=2E>
> }
> <=2E=2E=2E use the heap copy =2E=2E=2E>
> <=2E=2E=2E destroy the heap copy before returning =2E=2E=2E>
>}
Exactly! More specifically, if you specify that an "atomic signal fence" o=
ccur after the array write, you guarantee that the value is untorn=2E I thi=
nk you'd also want to make the array volatile to prevent the compiler tryin=
g to optimize it out entirely because it can't see the array being read by =
anything=2E
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 13 Oct 2025 15:28:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 13 11:28:57 2025
Received: from localhost ([127.0.0.1]:52567 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v8KTo-0006jX-9Y
for submit <at> debbugs.gnu.org; Mon, 13 Oct 2025 11:28:57 -0400
Received: from mail-4316.protonmail.ch ([185.70.43.16]:43569)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1v8KTk-0006jC-05
for 79584 <at> debbugs.gnu.org; Mon, 13 Oct 2025 11:28:53 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1760369324; x=1760628524;
bh=ew2zPA0653/yqfcvWQ8nQN6Ls+FGTa0eq6VRNEod+4A=;
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;
b=vQB8gi4osnBBrcXtF/hpSmstnRmtESIM6hiAgF0eJcoPvSLTQ0F9xvtIdIQwkQSjA
cGgOj5f4zuKCdGuNcalDDTSUDQU5EaMDzCsxOCaLv21cSjBPDAJ/56rYm8zDKlLuc6
4BbTgaTQRkK/JxtNrGu7oqfPN5FmWyBolnJkctaNP626FMBDzRzuwdyhYy/wFA17mo
h8ZztDho89brQorhA+jtzbRux1vjgbVO4Rm2XQKlZ1tg2wNFgdZtHENw63Sqr8w8za
ZTkYobg5A3D0T2GqEi+Y8HmaIQqZGvINTro7NqZC1D10dsb+0upKDqmR9j682p42Na
HNubuAn0CdKVg==
Date: Mon, 13 Oct 2025 15:28:42 +0000
To: Daniel Colascione <dancol@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
Message-ID: <87bjmayg8z.fsf@HIDDEN>
In-Reply-To: <8FACC7A1-F7E1-47E9-AC12-9CB1CA89582D@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <87347rxo57.fsf@HIDDEN>
<m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN>
<m2wm50ig2j.fsf@HIDDEN> <m2sefoicun.fsf@HIDDEN>
<871pn8yrhh.fsf@HIDDEN> <86ecr748xw.fsf@HIDDEN>
<8FACC7A1-F7E1-47E9-AC12-9CB1CA89582D@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: cd7e82cf6f57606c5a22183268bacb2da5aef583
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: 79584
Cc: 79584 <at> debbugs.gnu.org, oliver.reiter@HIDDEN, eller.helmut@HIDDEN,
gerd.moellmann@HIDDEN, Philipp Stephani <p.stephani2@HIDDEN>,
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:
> On October 12, 2025 11:22:51 PM PDT, Eli Zaretskii <eliz@HIDDEN> wrote:
>>> Date: Sun, 12 Oct 2025 17:13:43 +0000
>>> From: Pip Cet <pipcet@HIDDEN>
>>> Cc: Helmut Eller <eller.helmut@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>=
, oliver.reiter@HIDDEN, 79584 <at> debbugs.gnu.org
>>
>>Since we are discussing various design changes for emacs modules, I
>>think we should bring Daniel and Philipp on-board of the discussion.
Thanks!
I fear I'm a little confused here: the code I'm proposing lets you do
whatever you want with an emacs_value: when the last environment goes
out of scope, we consider whether to collect the negatively-indexed hash
entries.
The API documentation change I'm proposing would make it easier for
future code to overcome this limitation, should that become necessary,
by limiting what you can validly do with an emacs_value (which depends
on whether it was a global reference or not).
>>Daniel and Philipp, any comments or suggestions on the issues
>>discussed in this thread?
>>
>>> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
>>>
>>> > Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
>>> >
>>> >> Pip Cet <pipcet@HIDDEN> writes:
>>> >>
>>> >>> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
>>> >>>
>>> >>>> Helmut Eller <eller.helmut@HIDDEN> writes:
>>> >>>>
>>> >>>>> On Thu, Oct 09 2025, Gerd M=C3=B6llmann wrote:
>>> >>>>>
>>> >>>>>>> It would mean that all objects referenced by the AMS pool are p=
inned.
>>> >>>>>>> Which could be useful.
>>> >>>>>>
>>> >>>>>> Who makes sure that objects in AMS get scanned and pin reference=
d
>>> >>>>>> objects? How does MPS detect when references in AMS objects chan=
ge when
>>> >>>>>> there are no barriers? Ans so on.
>>> >>>>>
>>> >>>>> It looks like it's not implemented. I added the MPS_KEY_RANK arg=
ument,
>>> >>>>> but then (require 'vterm) triggers this assertion:
>>> >>>>>
>>> >>>>> #5 traceFindGrey (segReturn=3D<synthetic pointer>,
>>> >>>>> rankReturn=3D<synthetic pointer>, arena=3D0x7ffff7fbe000, ti=
=3D0)
>>> >>>>> at ../mps/code/trace.c:1103
>>> >>>>> 1103=09 AVER(RingIsSingle(ArenaGreyRing(arena, RankAMBIG)));
>>> >>>>>
>>> >>>>> Disappointing.
>>> >>>>
>>> >>>> Please find attached the "final" version of what I have in my Emac=
s,
>>> >>>> ported to feature/igc. No further gymnastics needed for modules. I=
'd
>>> >>>> like to apply that, okay with you?
>>> >>>
>>> >>> Does this work with the PVEC_THREAD allocation? The reason for usin=
g
>>> >>> alloc_immovable there was to avoid barriers, and now we're allocati=
ng
>>> >>> from a pool which does have barriers.
>>> >>>
>>> >>
>>> >> It works on macOS at least, AFAICT, but I also don't remember 1 bit
>>> >> about that subject, so maybe it doesn't work on other systems?
>>> >
>>> > Looking at thread_state, I see, as one would expect, it has Lisp_Obje=
ct
>>> > members. When one of these objects moves in memory, these references
>>> > must be updated. So far so good and normal.
>>> >
>>> > How does this updating of references work, if thread_state does not h=
ave
>>> > barriers?
>>>
>>> I'm very confused now, having run some experiments. The behavior I'm
>>> observing is this:
>>>
>>> * when a trace starts, the AMS segments are unprotected. That's okay,
>>> because MPS knows they're not reachable directly from the roots (all
>>> reachability paths go through a barriered segment)
>>> * symbols move, but the AMS segment remains unprotected.
>>> * when you look at the AMC segment containing the Vmodule_refs_hash has=
h
>>> table, MPS protects the AMS segment (????)
>>> * when you access the AMS segment afterwards, you hit the barrier and
>>> the reference gets fixed before you use it.
>>>
>>> I think this is rather confusing, particularly the step labelled (????)=
.
>>> AMS is documented not to have barriers, but AMSSeg inherits from
>>> MutatorSeg, which installs barriers (as observed) when the segment
>>> becomes grey.
>>>
>>> Our problem, whether or not barriers are used, is that we accessed a
>>> segment that was considered white, and I don't think that's okay whethe=
r
>>> you're talking about AMS or AMC.
>>>
>>> I think.
>>>
>>> > My answer is that it can't, and if AMS hadn't falsely claimed
>>> > to work with references to other pools, that would have been obvious
>>> > from the start.
>>>
>>> AMS works with references to other pools to the same extent that AMC
>>> does, AFAIU. You can't stash away a pointer to what used to be a valid
>>> object in either pool, then dereference it, unless you tell MPS about
>>> the pointer first.
>>>
>>> But the other limitations of AMS make it a bad choice: we need ambiguou=
s
>>> interior pointers keeping objects alive.
>>>
>>> So my proposal is to give up as far as possible on immovable objects an=
d
>>> huge ambiguous roots, whether on the stack or the heap.
>>>
>>> Here's my idea:
>>>
>>> An emacs_value is a hash index (if we want to keep it a pointer, we can
>>> either cast an integer to a pointer or make it a pointer to an integer
>>> on the heap somewhere, or assume LISP_WORDS_ARE_POINTERS and simply cas=
t
>>> a fixnum to emacs_value). If the index is positive, the object is
>>> global, and has to be recycled explicitly. If the index is negative, th=
e
>>> object can go away as soon as the environment it's in dies; in practice=
,
>>> I believe it's probably sufficient to recycle such objects once the las=
t
>>> local environment goes out of scope, and only if there are too many suc=
h
>>> references or debugging is enabled.
>>>
>>> No immovable objects. No refcounting. A simple single index-to-object
>>> hash table, which gets rebuilt (and thus shrunk) when it's convenient
>>> (all module environments went out of scope).
>>>
>>> If there are problems with long-lived module environments (or multiple
>>> independent module environments making it so we never reach the "all
>>> module environments are dead" point), we can deal with that
>>> complication. Let's burn that bridge when we come to it.
>>>
>>> Plenty of silly possible optimizations, of course, but do we need to
>>> deal with those? I suspect not.
>>>
>>> But just to be on the sure side, let's modify the documented module API
>>> in this way:
>>>
>>> 1. If you obtain an emacs_value from module_make_global_ref, you can do
>>> with it what you want: it can live in registers, on the stack, on the
>>> heap, and you can even serialize it (send it over the network or save i=
t
>>> to disk) and unserialize it back to an emacs_value if you must for some
>>> reason do so. But you must free it when done or it's Emacs (not your
>>> module) which leaks valuable memory and slows down other modules.
>>>
>>> 2. If you obtain an emacs_value elsewhere, you must treat it as a
>>> potentially GCable object. You can keep it on the stack (or in a
>>> register, which compilers give you no control over these days), but you
>>> can't store it on the heap, obfuscate or munge it, serialize it, etc.
>>> If you must do so, you need to turn it into a global ref and free it
>>> when done.
>
> Let's be a bit more precise about the requirement: you can put one of
> these values on the heap or do whatever you want with it, but its
> value lifetime extends only so long as a GC scan of the stack and
> registers can find it, and (IIUC) this scan can happen any
> time. Correct? Compilers can and do occasionally tear values when they
> think nobody's looking.
I think "make sure one copy is on the stack, but it won't be modified
there so you can use another copy which is more convenient" is a useful,
and necessary, addition to the API proposal! Thanks!
IOW, things like
function()
{
{
emacs_value v =3D ...;
memcpy (alloca (sizeof v), &v, sizeof v);
<... put a copy of v on the heap ...>
}
<... use the heap copy ...>
<... destroy the heap copy before returning ...>
}
should be documented to be safe. In particular, this should allow
handing off an emacs_value to another thread.
MPS is indeed documented to allow GC between any pair of instructions,
and I did perform test runs by triggering GC from another thread
asynchronously.
> Also, you probably want to make these values large and hard to stumble
> upon randomly: you'll get a lot of false positives on conservative
> scanning for small numbers.
On 64-bit systems, I agree. However, IMHO, we do not want to use 64-bit
emacs_values on 32-bit systems because GCC might rip them apart into
non-contiguous stack locations.
> BTW, I know nobody likes an "I told you so", but it's precisely
> because of situations like this that I proposed making emacs_value
> work like JNI values, complete with stack semantics and no
> conservative scanning, way back when.
> LTGM, except...
Makes sense to me.
Pip
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 13 Oct 2025 06:55:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 13 02:55:43 2025 Received: from localhost ([127.0.0.1]:51011 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v8CT9-0000hx-6S for submit <at> debbugs.gnu.org; Mon, 13 Oct 2025 02:55:43 -0400 Received: from dancol.org ([2600:3c01:e000:3d8::1]:56174) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <dancol@HIDDEN>) id 1v8CT3-0000hk-FZ for 79584 <at> debbugs.gnu.org; Mon, 13 Oct 2025 02:55:40 -0400 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=F5pc1V9y5wE5SRZ1aTp686r0+i5/YWc7Zt8q0DFSJqQ=; b=hN61Zjqg1AVIknIcr8kqR5N2ji Rr5+YJ7TUgfDUXEEqPeAWSO2neXi3+B8F+oFqiIU4H1O7aZ7pqsdwXZ8WZHqWLqq1QvguSxX0Co1x p0ILS8zazRQ0fMeDF3ZnKXUiomES4gETscdBuKmuvwPMRrOHKJ1yDiSdU7hodLk37et0BKMs0aahK Qtp18l/+TBEEBQzn3ct0OY7Okdsyix57FlvHNwwwbk+I9YMktZXR9DOh6yfjtC8wLxFboHpCU2gSn q/0AXBHtTRMTA+7QXyqotIvLrR/ZpaCpDi0Tbs6tv9e5IH50rUX5c0+T9DyN68DuMCnlzph/pU7io wfW6R67w==; Received: from [2600:1010:b00b:eee4:0:3:e35a:d701] (port=55520 helo=ehlo.thunderbird.net) by dancol.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from <dancol@HIDDEN>) id 1v8CQ5-003ldv-0m; Mon, 13 Oct 2025 02:52:33 -0400 Date: Sun, 12 Oct 2025 23:55:19 -0700 From: Daniel Colascione <dancol@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN>, Pip Cet <pipcet@HIDDEN>, Philipp Stephani <p.stephani2@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm User-Agent: K-9 Mail for Android In-Reply-To: <86ecr748xw.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <871pnbdhw8.fsf@HIDDEN> <877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN> <87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN> <m2sefoicun.fsf@HIDDEN> <871pn8yrhh.fsf@HIDDEN> <86ecr748xw.fsf@HIDDEN> Message-ID: <8FACC7A1-F7E1-47E9-AC12-9CB1CA89582D@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: 79584 Cc: gerd.moellmann@HIDDEN, oliver.reiter@HIDDEN, 79584 <at> debbugs.gnu.org, eller.helmut@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 (-) On October 12, 2025 11:22:51 PM PDT, Eli Zaretskii <eliz@gnu=2Eorg> wrote: >> Date: Sun, 12 Oct 2025 17:13:43 +0000 >> From: Pip Cet <pipcet@protonmail=2Ecom> >> Cc: Helmut Eller <eller=2Ehelmut@gmail=2Ecom>, Eli Zaretskii <eliz@gnu= =2Eorg>, oliver=2Ereiter@snapdragon=2Ecc, 79584@debbugs=2Egnu=2Eorg > >Since we are discussing various design changes for emacs modules, I >think we should bring Daniel and Philipp on-board of the discussion=2E > >Daniel and Philipp, any comments or suggestions on the issues >discussed in this thread? > >> Gerd M=C3=B6llmann <gerd=2Emoellmann@gmail=2Ecom> writes: >>=20 >> > Gerd M=C3=B6llmann <gerd=2Emoellmann@gmail=2Ecom> writes: >> > >> >> Pip Cet <pipcet@protonmail=2Ecom> writes: >> >> >> >>> Gerd M=C3=B6llmann <gerd=2Emoellmann@gmail=2Ecom> writes: >> >>> >> >>>> Helmut Eller <eller=2Ehelmut@gmail=2Ecom> writes: >> >>>> >> >>>>> On Thu, Oct 09 2025, Gerd M=C3=B6llmann wrote: >> >>>>> >> >>>>>>> It would mean that all objects referenced by the AMS pool are p= inned=2E >> >>>>>>> Which could be useful=2E >> >>>>>> >> >>>>>> Who makes sure that objects in AMS get scanned and pin reference= d >> >>>>>> objects? How does MPS detect when references in AMS objects chan= ge when >> >>>>>> there are no barriers? Ans so on=2E >> >>>>> >> >>>>> It looks like it's not implemented=2E I added the MPS_KEY_RANK a= rgument, >> >>>>> but then (require 'vterm) triggers this assertion: >> >>>>> >> >>>>> #5 traceFindGrey (segReturn=3D<synthetic pointer>, >> >>>>> rankReturn=3D<synthetic pointer>, arena=3D0x7ffff7fbe000, ti= =3D0) >> >>>>> at =2E=2E/mps/code/trace=2Ec:1103 >> >>>>> 1103 AVER(RingIsSingle(ArenaGreyRing(arena, RankAMBIG))); >> >>>>> >> >>>>> Disappointing=2E >> >>>> >> >>>> Please find attached the "final" version of what I have in my Emac= s, >> >>>> ported to feature/igc=2E No further gymnastics needed for modules= =2E I'd >> >>>> like to apply that, okay with you? >> >>> >> >>> Does this work with the PVEC_THREAD allocation? The reason for usin= g >> >>> alloc_immovable there was to avoid barriers, and now we're allocati= ng >> >>> from a pool which does have barriers=2E >> >>> >> >> >> >> It works on macOS at least, AFAICT, but I also don't remember 1 bit >> >> about that subject, so maybe it doesn't work on other systems? >> > >> > Looking at thread_state, I see, as one would expect, it has Lisp_Obje= ct >> > members=2E When one of these objects moves in memory, these reference= s >> > must be updated=2E So far so good and normal=2E >> > >> > How does this updating of references work, if thread_state does not h= ave >> > barriers? >>=20 >> I'm very confused now, having run some experiments=2E The behavior I'm >> observing is this: >>=20 >> * when a trace starts, the AMS segments are unprotected=2E That's okay, >> because MPS knows they're not reachable directly from the roots (all >> reachability paths go through a barriered segment) >> * symbols move, but the AMS segment remains unprotected=2E >> * when you look at the AMC segment containing the Vmodule_refs_hash has= h >> table, MPS protects the AMS segment (????) >> * when you access the AMS segment afterwards, you hit the barrier and >> the reference gets fixed before you use it=2E >>=20 >> I think this is rather confusing, particularly the step labelled (????)= =2E >> AMS is documented not to have barriers, but AMSSeg inherits from >> MutatorSeg, which installs barriers (as observed) when the segment >> becomes grey=2E >>=20 >> Our problem, whether or not barriers are used, is that we accessed a >> segment that was considered white, and I don't think that's okay whethe= r >> you're talking about AMS or AMC=2E >>=20 >> I think=2E >>=20 >> > My answer is that it can't, and if AMS hadn't falsely claimed >> > to work with references to other pools, that would have been obvious >> > from the start=2E >>=20 >> AMS works with references to other pools to the same extent that AMC >> does, AFAIU=2E You can't stash away a pointer to what used to be a vali= d >> object in either pool, then dereference it, unless you tell MPS about >> the pointer first=2E >>=20 >> But the other limitations of AMS make it a bad choice: we need ambiguou= s >> interior pointers keeping objects alive=2E >>=20 >> So my proposal is to give up as far as possible on immovable objects an= d >> huge ambiguous roots, whether on the stack or the heap=2E >>=20 >> Here's my idea: >>=20 >> An emacs_value is a hash index (if we want to keep it a pointer, we can >> either cast an integer to a pointer or make it a pointer to an integer >> on the heap somewhere, or assume LISP_WORDS_ARE_POINTERS and simply cas= t >> a fixnum to emacs_value)=2E If the index is positive, the object is >> global, and has to be recycled explicitly=2E If the index is negative, = the >> object can go away as soon as the environment it's in dies; in practice= , >> I believe it's probably sufficient to recycle such objects once the las= t >> local environment goes out of scope, and only if there are too many suc= h >> references or debugging is enabled=2E >>=20 >> No immovable objects=2E No refcounting=2E A simple single index-to-obje= ct >> hash table, which gets rebuilt (and thus shrunk) when it's convenient >> (all module environments went out of scope)=2E >>=20 >> If there are problems with long-lived module environments (or multiple >> independent module environments making it so we never reach the "all >> module environments are dead" point), we can deal with that >> complication=2E Let's burn that bridge when we come to it=2E >>=20 >> Plenty of silly possible optimizations, of course, but do we need to >> deal with those? I suspect not=2E >>=20 >> But just to be on the sure side, let's modify the documented module API >> in this way: >>=20 >> 1=2E If you obtain an emacs_value from module_make_global_ref, you can = do >> with it what you want: it can live in registers, on the stack, on the >> heap, and you can even serialize it (send it over the network or save i= t >> to disk) and unserialize it back to an emacs_value if you must for some >> reason do so=2E But you must free it when done or it's Emacs (not your >> module) which leaks valuable memory and slows down other modules=2E >>=20 >> 2=2E If you obtain an emacs_value elsewhere, you must treat it as a >> potentially GCable object=2E You can keep it on the stack (or in a >> register, which compilers give you no control over these days), but you >> can't store it on the heap, obfuscate or munge it, serialize it, etc=2E >> If you must do so, you need to turn it into a global ref and free it >> when done=2E Let's be a bit more precise about the requirement: you can put one of thes= e values on the heap or do whatever you want with it, but its value lifetim= e extends only so long as a GC scan of the stack and registers can find it,= and (IIUC) this scan can happen any time=2E Correct? Compilers can and do = occasionally tear values when they think nobody's looking=2E Also, you probably want to make these values large and hard to stumble upo= n randomly: you'll get a lot of false positives on conservative scanning fo= r small numbers=2E BTW, I know nobody likes an "I told you so", but it's precisely because of= situations like this that I proposed making emacs_value work like JNI valu= es, complete with stack semantics and no conservative scanning, way back wh= en=2E=20 LTGM, except=2E=2E=2E
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 13 Oct 2025 06:23:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 13 02:23:10 2025 Received: from localhost ([127.0.0.1]:50966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v8Bxd-0007X1-K2 for submit <at> debbugs.gnu.org; Mon, 13 Oct 2025 02:23:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56162) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1v8BxZ-0007WF-Gx for 79584 <at> debbugs.gnu.org; Mon, 13 Oct 2025 02:23:06 -0400 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 1v8BxR-0006Yd-Ac; Mon, 13 Oct 2025 02:22:57 -0400 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=zoPi6t0+0ohjkn5DDkLd3uoVlBGiXupn9dwh3b/df20=; b=k9nmZtNxtBvroPmXKvul huL/sKoXYoXlEk4buKRMgLcQwAFPqggOzvTTqczz24TVh2XpY5VdYwie79W9J62zfQoofgUUpU7RL 1lsIC8zdMX8D6tXjERzTdOZJK5B1thcVVjJR4c1Kev0jaLgi0mGYXVh7TQ6MqZTwF8eLFizIoWbJ3 lGQ4ADcWsOLlCANuWJrLmb8e+yt0BI78GaXa6RpEXF8vsAvHb+Ivho72R5MHqr1cwXUEEh+zdeRuW bjg5Jp5vlfiagqAT63cwCR/dKVEz55DCyhk2lVMTPFFibCmdMdJVEys2QPoLxRlQVbSDhe9JEbIcM JQao15auu7YD3Q==; Date: Mon, 13 Oct 2025 09:22:51 +0300 Message-Id: <86ecr748xw.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN>, Daniel Colascione <dancol@HIDDEN>, Philipp Stephani <p.stephani2@HIDDEN> In-Reply-To: <871pn8yrhh.fsf@HIDDEN> (message from Pip Cet on Sun, 12 Oct 2025 17:13:43 +0000) Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm References: <874iscb5i8.fsf_-_@HIDDEN> <871pnbdhw8.fsf@HIDDEN> <877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN> <87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN> <m2sefoicun.fsf@HIDDEN> <871pn8yrhh.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: 79584 Cc: gerd.moellmann@HIDDEN, oliver.reiter@HIDDEN, 79584 <at> debbugs.gnu.org, eller.helmut@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: -3.3 (---) > Date: Sun, 12 Oct 2025 17:13:43 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: Helmut Eller <eller.helmut@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, oliver.reiter@HIDDEN, 79584 <at> debbugs.gnu.org Since we are discussing various design changes for emacs modules, I think we should bring Daniel and Philipp on-board of the discussion. Daniel and Philipp, any comments or suggestions on the issues discussed in this thread? > Gerd Möllmann <gerd.moellmann@HIDDEN> writes: > > > Gerd Möllmann <gerd.moellmann@HIDDEN> writes: > > > >> Pip Cet <pipcet@HIDDEN> writes: > >> > >>> Gerd Möllmann <gerd.moellmann@HIDDEN> writes: > >>> > >>>> Helmut Eller <eller.helmut@HIDDEN> writes: > >>>> > >>>>> On Thu, Oct 09 2025, Gerd Möllmann wrote: > >>>>> > >>>>>>> It would mean that all objects referenced by the AMS pool are pinned. > >>>>>>> Which could be useful. > >>>>>> > >>>>>> Who makes sure that objects in AMS get scanned and pin referenced > >>>>>> objects? How does MPS detect when references in AMS objects change when > >>>>>> there are no barriers? Ans so on. > >>>>> > >>>>> It looks like it's not implemented. I added the MPS_KEY_RANK argument, > >>>>> but then (require 'vterm) triggers this assertion: > >>>>> > >>>>> #5 traceFindGrey (segReturn=<synthetic pointer>, > >>>>> rankReturn=<synthetic pointer>, arena=0x7ffff7fbe000, ti=0) > >>>>> at ../mps/code/trace.c:1103 > >>>>> 1103 AVER(RingIsSingle(ArenaGreyRing(arena, RankAMBIG))); > >>>>> > >>>>> Disappointing. > >>>> > >>>> Please find attached the "final" version of what I have in my Emacs, > >>>> ported to feature/igc. No further gymnastics needed for modules. I'd > >>>> like to apply that, okay with you? > >>> > >>> Does this work with the PVEC_THREAD allocation? The reason for using > >>> alloc_immovable there was to avoid barriers, and now we're allocating > >>> from a pool which does have barriers. > >>> > >> > >> It works on macOS at least, AFAICT, but I also don't remember 1 bit > >> about that subject, so maybe it doesn't work on other systems? > > > > Looking at thread_state, I see, as one would expect, it has Lisp_Object > > members. When one of these objects moves in memory, these references > > must be updated. So far so good and normal. > > > > How does this updating of references work, if thread_state does not have > > barriers? > > I'm very confused now, having run some experiments. The behavior I'm > observing is this: > > * when a trace starts, the AMS segments are unprotected. That's okay, > because MPS knows they're not reachable directly from the roots (all > reachability paths go through a barriered segment) > * symbols move, but the AMS segment remains unprotected. > * when you look at the AMC segment containing the Vmodule_refs_hash hash > table, MPS protects the AMS segment (????) > * when you access the AMS segment afterwards, you hit the barrier and > the reference gets fixed before you use it. > > I think this is rather confusing, particularly the step labelled (????). > AMS is documented not to have barriers, but AMSSeg inherits from > MutatorSeg, which installs barriers (as observed) when the segment > becomes grey. > > Our problem, whether or not barriers are used, is that we accessed a > segment that was considered white, and I don't think that's okay whether > you're talking about AMS or AMC. > > I think. > > > My answer is that it can't, and if AMS hadn't falsely claimed > > to work with references to other pools, that would have been obvious > > from the start. > > AMS works with references to other pools to the same extent that AMC > does, AFAIU. You can't stash away a pointer to what used to be a valid > object in either pool, then dereference it, unless you tell MPS about > the pointer first. > > But the other limitations of AMS make it a bad choice: we need ambiguous > interior pointers keeping objects alive. > > So my proposal is to give up as far as possible on immovable objects and > huge ambiguous roots, whether on the stack or the heap. > > Here's my idea: > > An emacs_value is a hash index (if we want to keep it a pointer, we can > either cast an integer to a pointer or make it a pointer to an integer > on the heap somewhere, or assume LISP_WORDS_ARE_POINTERS and simply cast > a fixnum to emacs_value). If the index is positive, the object is > global, and has to be recycled explicitly. If the index is negative, the > object can go away as soon as the environment it's in dies; in practice, > I believe it's probably sufficient to recycle such objects once the last > local environment goes out of scope, and only if there are too many such > references or debugging is enabled. > > No immovable objects. No refcounting. A simple single index-to-object > hash table, which gets rebuilt (and thus shrunk) when it's convenient > (all module environments went out of scope). > > If there are problems with long-lived module environments (or multiple > independent module environments making it so we never reach the "all > module environments are dead" point), we can deal with that > complication. Let's burn that bridge when we come to it. > > Plenty of silly possible optimizations, of course, but do we need to > deal with those? I suspect not. > > But just to be on the sure side, let's modify the documented module API > in this way: > > 1. If you obtain an emacs_value from module_make_global_ref, you can do > with it what you want: it can live in registers, on the stack, on the > heap, and you can even serialize it (send it over the network or save it > to disk) and unserialize it back to an emacs_value if you must for some > reason do so. But you must free it when done or it's Emacs (not your > module) which leaks valuable memory and slows down other modules. > > 2. If you obtain an emacs_value elsewhere, you must treat it as a > potentially GCable object. You can keep it on the stack (or in a > register, which compilers give you no control over these days), but you > can't store it on the heap, obfuscate or munge it, serialize it, etc. > If you must do so, you need to turn it into a global ref and free it > when done. > > 3. There is no guarantee that identical objects have identical > emacs_values, not even if you try to create the same global ref twice. > > 4. While emacs_value will usually "look like" a pointer, we make no > guarantees about its alignedness, tag bits, or anything else. > > > IOW, I think if a requirement exists that thread_state must not have > > barriers, that must be solved differently. As I said, I don't remember > > such a requirement at all. Do you remember more, Pip? > > It seems AMS segments use barriers, but not at all times when we would > expect them to. If you need barrier-free memory, use xmalloc? > > I'd really like to unify emacs_value (as used by modules) with the > opaque pointer required by other callbacks. I think these days, everyone > uses void * for opaque pointers, and void * is equivalent to a pointer > to an undeclared struct on all current systems, so there's no binary > incompatibility, even if the C magic is unsatisfactory. > > If we want high performance, we should: > > 1. make the pointer word representing a Lisp value use tag 1 (or another > nonzero tag) > > 2. choose a pseudorandom starting point integer when we start Emacs, so > conservative GC can recognize such pointers with some certainty. > > 3. (possibly) make it so when we rebuild the hash table, > positively-numbered Lisp_Objects appear at their hash index, which would > save us a hash lookup once in a while. > > Pip > >
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 13 Oct 2025 03:52:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 23:52:10 2025 Received: from localhost ([127.0.0.1]:50693 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v89bW-0007Fy-3M for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 23:52:10 -0400 Received: from mail-wr1-x42d.google.com ([2a00:1450:4864:20::42d]:57698) 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 1v89bT-0007FN-Bj for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 23:52:08 -0400 Received: by mail-wr1-x42d.google.com with SMTP id ffacd0b85a97d-4060b4b1200so2537103f8f.3 for <79584 <at> debbugs.gnu.org>; Sun, 12 Oct 2025 20:52:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760327521; x=1760932321; 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=HtF7GDOox/eN8KpThUoxw08M4hjqu+zq3MwCAF6mFiE=; b=UOt9rbX04GjI1OuD9kwcIdYCMgU7u8CM5uuKTeTWfq8OXi85CPBSV8jj6V5wVh7dT6 LWqhHCGEe1mlvwjjRtgl9c597fIaTEszSEzhfjUudVlwUvn3I+FYQTOq/mVtqrGav7HW bqh+FMTAhiQGVfs+ngze/ECFT6Eywa2H7zg2ClpUx3f8xKahQOsY/BVH2W3YfE3bmvZQ ByMuwgOPxD4+UFRnfbh6nkYOAarQNOuXxeGsODu9iMOeTVoEuShzvg65hXC0W+kpah0U R/vSqUq8oy+Q1k1b8oAC8OlmgocNj/QaH1MCYRtaZgVJViKj3K7U1E3lPXNAhRGtaufj wqwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760327521; x=1760932321; 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=HtF7GDOox/eN8KpThUoxw08M4hjqu+zq3MwCAF6mFiE=; b=hqgU9JslXn3xNToC5f7pzBYFqxO+NrSnKVui/o4bscs05eBBwCIbY1So0YQVQKO+Jx aMpOoLvVx034XhodxIyvcH+Oqlsv8YIRNRKvK1wwwTmVA+O/8GpXiMiEWqYQbDu2T0U3 ZiBsfGwt/nsXQVYpC0yWhjatY67MyzmPaVzIzI5nyvGrWedQ6qsb+/68lh2QQGCkWOUZ scjKZPhaa4tfD2f+K4ZDxYUTKpFpkIBcW3jkHTfPNBbXSo/oQhXgp3ey7EN6ScIqVDPr VJA+r6GmWvXdCJvJKxDq2BxFmoLApCgcuTiLl0lCEdDUySNoWlmXwf4Le71ueAkGqJd1 zEKg== X-Forwarded-Encrypted: i=1; AJvYcCWdAiebotw+CmZFWogjLEOe9KtcwJUqXdv5B6MIPb4q3bB8dl7EbHZ6kT4ZpgGR+XYk+SGIrA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yzh/R/hNo7fONu6UdBvmUnC27d/ndzvyUizGUWkEsXFd4Kr/SKz TAJK54S9xs20PTP2TcNPjmJAP+uZLMImr6t22/v/f8q6ljYFOll+c6Ye89g0sg== X-Gm-Gg: ASbGnctNCRdfxwYTbOCTza8MMvV0oymEB+Dqe7H4yC2DXcoOdWHUTB8bRqrqhKyCf2x FHky8F6WELvwgfPyNfftLX11g/+HWuVMyb0ruuwvY43QKkAc8rndB2RJ4aEPO1RqNWlqeCLm7Be OBOn1QVzOl6aGMj/PBfsCkPSRHM0yIf4gdGihIXlbBYIpan1Hpoz8ED6tND1xzENXgEBE06hZXi /3xw0/l3NfuAxi1ocjoCKgj55JW1ziye08lPg0RIPL6zEo+qHknew+XpTQJ/A5/2zBSXCKlcU9Y CvRoc5+s/9Vp6Wk7mz2lZmAkY3Cc8BIOw+2hVIidv4DYVvwJklCnMOxjSv2EIYp1qcxEDH6oVJf 7gD3cngwzKu9as7WJ1Jq392xYvrcmUMlp6PDM2NZDTAYs1me3MuJFTjITQSrHIB3x5IDH3gOUmj IDBroerdpExJPZxdMmGaGnTNDAi72Zr9qoa2rh9x2Y1sjMH3Y88TR0qh/ozAEa X-Google-Smtp-Source: AGHT+IHIgEOVBYOADGZIjJj9LypUOSb0XpBtuk9+F9ofWCfR5UijlECfFnq/d9fKajsAT5vzFXGmTQ== X-Received: by 2002:a05:6000:4283:b0:3e8:b4cb:c3dc with SMTP id ffacd0b85a97d-4266e7ce955mr13195933f8f.3.1760327520727; Sun, 12 Oct 2025 20:52:00 -0700 (PDT) Received: from pro4 (p200300e0b7379600f1da6832ebd2b3b2.dip0.t-ipconnect.de. [2003:e0:b737:9600:f1da:6832:ebd2:b3b2]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-426ce57d3desm16078239f8f.7.2025.10.12.20.51.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Oct 2025 20:51:59 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <87h5w3xz61.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN> <m2sefoicun.fsf@HIDDEN> <871pn8yrhh.fsf@HIDDEN> <m2o6qchs9e.fsf@HIDDEN> <87sefnylcc.fsf@HIDDEN> <m2qzv7nbo9.fsf@HIDDEN> <87h5w3xz61.fsf@HIDDEN> Date: Mon, 13 Oct 2025 05:51:57 +0200 Message-ID: <m2v7kja276.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: 79584 Cc: oliver.reiter@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, Helmut Eller <eller.helmut@HIDDEN>, 79584 <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: > So make 'bc' a pointer to non-MPS-managed memory, which we can access > freely from the scanning function? LGTM. I'm running with it now. Not that I expect any problems.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 13 Oct 2025 03:31:32 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 23:31:32 2025 Received: from localhost ([127.0.0.1]:50624 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v89HY-00063t-0C for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 23:31:32 -0400 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:47239) 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 1v89HU-00063b-Ef for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 23:31:29 -0400 Received: by mail-wr1-x435.google.com with SMTP id ffacd0b85a97d-3ed20bdfdffso3261518f8f.2 for <79584 <at> debbugs.gnu.org>; Sun, 12 Oct 2025 20:31:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760326282; x=1760931082; 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=sYGjMuGwI5mkWME8vbOAZAs32A6kIsNuVWzXC5CjgKo=; b=Xwa1q5ro0ozksgO1bTrhHKuka0RonmXXp9dTUGn8SJRCxprSc/apQV3amQcKzr7pAe Ls09XUS5UhNg8wdqcux8eP4GytWNekNIQfJ5H0b7WSu6CWBVRLSF723CUW31VVKmpQlk BeA+3S00c7FFQXKlO84zyqiihLN0wGl7H6MnVMk48P3ZPiJNo1uD2rsn6Oqo7MFf4Cfd ckHIMXjm53fLL0eZJ2wlZFnU5sKaB5e8B7HJEL8B0QB41uq6531hU+OVpb80yYqLr9E7 oxjysR1S8QNnkyFuRIcg6m1lNLN8b9a2NcY3btgQ9dqgvfwrHiws24WMcoS3e4BjG1Lz VeVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760326282; x=1760931082; 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=sYGjMuGwI5mkWME8vbOAZAs32A6kIsNuVWzXC5CjgKo=; b=jSWFMPQzCoXnVsqtO/U9OV1odij30o+OKmpt6C9j8XX0qd4jjP+qSRZ6uRI/OmBimD yWsIcKqw/7COGyTzb29CB6pxlKc4FGQEWcodO3iINmFP9bXcozxzpqId89K+rbzKDD7W kp7GYsLZISKEJhVacfFFFQJ6YbL4MgzVWvbcFPx0x/HFAqAwzztxu1mABfbITP22KohX hZj6QrsJtrlkh96fEvro7U2umD7inrGs1paG7a5m//SkYNrLRujbB7xzGqyy/0t7aX0a 71q5hqKy0miGT2cblZ67BtD3VQytMbvRVbDKfJj9rCwi69+aocQ/weXhcEl7lP2g+rWo riXw== X-Forwarded-Encrypted: i=1; AJvYcCUh69ycu7/ZMh/KCNSjfykgyuNTMSuMA8oYl0at5Nlj3augjCs/iqivIOrCaHIYsljdDKqB6A==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwhZRVhSnFn+Yxn5Cno+wCV4y2UuobzqFlgGw1EoxzK0usC61on NxjK6rVgLRWGVR9osD0DewU+iI0zI0Pu3osxCjyGsipgA2P2akaERqVwdkB1Nw== X-Gm-Gg: ASbGncvWYSQWABRFcdrj/PW4On8VhRTdSafJwsbaDCZe3FzC66VGxS7OhyRgur3jJ5G +OZTbsdhY6CpkrRi7TMKMjq0RRkYQkxGBZZ5zQkv9GtPJl+IrGClQu6/juE/5w7aAMlPxli3ks1 Rp6hCBDpdq0COdKXSrRWnnRIw/vm+k7vGBtUR8TKIx01t2OkbHyD1Af77xB4W7s6piiHN2Tb8nt yOebqvOOr2/d0+eriFNHnB4+pZIi3aMRSbDYiWsXlaQOPkJt2/4aonu/Fu8KeS4i86K52YqUsNZ NDbZUR9aQ2HyZhKe2JPneD9Q8O1wyMLEevuHh04K2NAAkn0358LMAyKnrAGoJ7IETSonde839/J chfnmhWmPuUNHihxY9HyX9O1l4Y3v9TREmzK+zidBIOnLwLw2rNx94pByivmT/hqmvohTJbuKfQ 10ni3iwd0AmHmPXiluHLDmSGQRkTKQ9gQTiDMwVsLYGRaiwxB0BM79zoVn/h9I X-Google-Smtp-Source: AGHT+IEmCJR0sO3yTOonxo1BzCrRuS9AetuzSy0B0RfdaOOSlVSoxStm1hV6BdsevoaegvZ0qLBV5Q== X-Received: by 2002:a05:6000:2dc9:b0:425:86c8:c4ff with SMTP id ffacd0b85a97d-42666ac7259mr13002991f8f.22.1760326281602; Sun, 12 Oct 2025 20:31:21 -0700 (PDT) Received: from pro4 (p200300e0b7379600f1da6832ebd2b3b2.dip0.t-ipconnect.de. [2003:e0:b737:9600:f1da:6832:ebd2:b3b2]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-426ce5e8141sm15769736f8f.48.2025.10.12.20.31.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Oct 2025 20:31:20 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Helmut Eller <eller.helmut@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <87ldlf7u8n.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m2v7knnal7.fsf@HIDDEN> <87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN> <m2sefoicun.fsf@HIDDEN> <871pn8yrhh.fsf@HIDDEN> <m2o6qchs9e.fsf@HIDDEN> <87sefnylcc.fsf@HIDDEN> <m2qzv7nbo9.fsf@HIDDEN> <87ldlf7u8n.fsf@HIDDEN> Date: Mon, 13 Oct 2025 05:31:19 +0200 Message-ID: <m2jz0ziik8.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: 79584 Cc: 79584 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>, oliver.reiter@HIDDEN, 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 (-) Helmut Eller <eller.helmut@HIDDEN> writes: > So Gerd: please commit your patch. Done.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 13 Oct 2025 03:25:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 23:25:40 2025
Received: from localhost ([127.0.0.1]:50606 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v89Bs-0005mO-2j
for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 23:25:40 -0400
Received: from mail-24416.protonmail.ch ([109.224.244.16]:24317)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1v89Bn-0005m6-1N
for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 23:25:36 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1760325928; x=1760585128;
bh=wL55S09paEn5nOkRJG/CfThrgax/mF33tkfCJ8KPQmY=;
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;
b=O8fKqYi5Rmo7/T69u8dWwCZU+JjF2ChOBeMsOIkekpbl03ar5ydugf2xpCP1Hh8SL
EKQ6k5NwhIOaVOkWriGDr4HAsYPvwOqpCOOY4SqJYVBXcB029J+D8SBIZquSxFqHoF
eIlm4z3N8rYK6NUQPEtj1i9zvSC72qDnd2TwzuDqMojbMb0NsJY67iqf1vJ7b0qadr
cwjQvu51C/C4Mohs6lnoBEcKgQvQc5GG4iZBvevUPpil5Ihq9aTOCBwN/s49/yu9uU
+oPNfBpiii/anvA9zulBnO9GR8am3/SnnSTsd13fw7OS9xoWXXTcoOMtPwpGlonWzU
dPyooOymwWtdQ==
Date: Mon, 13 Oct 2025 03:25:24 +0000
To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
Message-ID: <87h5w3xz61.fsf@HIDDEN>
In-Reply-To: <m2qzv7nbo9.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <m21pn8jvy2.fsf@HIDDEN>
<87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN>
<m2sefoicun.fsf@HIDDEN> <871pn8yrhh.fsf@HIDDEN>
<m2o6qchs9e.fsf@HIDDEN> <87sefnylcc.fsf@HIDDEN>
<m2qzv7nbo9.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: a038d87e716cec4fb620f47281b66e754fa1dc27
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: 79584
Cc: oliver.reiter@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
Helmut Eller <eller.helmut@HIDDEN>, 79584 <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: -2.0 (--)
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
> Pip Cet <pipcet@HIDDEN> writes:
>
>> It adds what seems to me a large amount of infrastructure for managing
>> "pins" and an ambiguously-scanned root of unlimited size,
>
> Well, well. 50 loc and a root that is 64 words in reality...
You're right, it's not that bad (unless some module comes along and
creates a large number of values). Let's go with that for now.
>> and I'd prefer the much simpler fix I've described: An emacs_value is
>> a fixnum which you look up in a hash table when you want the object,
>> and it's removed from the hash table explicitly or (if it's negative)
>> when the last environment goes out of scope.
>
> Plus something for thread_state, please.
IIUC, thread_state contains the condvar which is used to signal the
death of the thread, so it cannot be freed until after we're sure no
other thread is waiting for it.
Somewhat questionable design, since it's unclear who owns the memory (we
could just store a pointer to a condvar which lives in the waiting
thread's memory), but probably not worth fixing now.
So make 'bc' a pointer to non-MPS-managed memory, which we can access
freely from the scanning function?
From ae8277c1b658f051f9befcd014e042876ace32fb Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Mon, 13 Oct 2025 03:15:07 +0000
Subject: [PATCH] [MPS] Use xmalloc to allocate 'bc_thread_state' struct
This struct cannot live in MPS-managed memory because it's required
for scanning the bytecode stack.
* src/bytecode.c (free_bc_thread) [MPS]: Free bytecode structure.
(Finternal_stack_stats, exec_byte_code):
* src/igc.c (scan_bc): Adjust.
(root_create_bc): Save 'bc' pointer.
* src/lisp.h (get_act_rec, set_act_rec):
* src/thread.c (mark_one_thread, finalize_one_thread): Adjust.
(Fmake_thread) [MPS]:
(init_threads) [MPS]: Allocate bytecode structure.
* src/thread.h (struct thread_state): Turn 'bc' member into a
pointer (MPS) or single-member array.
---
src/bytecode.c | 9 ++++++---
src/igc.c | 8 +++++---
src/lisp.h | 4 ++--
src/thread.c | 12 ++++++++----
src/thread.h | 6 ++++--
5 files changed, 25 insertions(+), 14 deletions(-)
diff --git a/src/bytecode.c b/src/bytecode.c
index 2ab28d231c5..4ef3f8b3f53 100644
--- a/src/bytecode.c
+++ b/src/bytecode.c
@@ -399,6 +399,9 @@ init_bc_thread (struct bc_thread_state *bc)
free_bc_thread (struct bc_thread_state *bc)
{
xfree (bc->stack);
+#ifdef HAVE_MPS
+ xfree (bc);
+#endif
}
=20
#ifndef HAVE_MPS
@@ -439,7 +442,7 @@ DEFUN ("internal-stack-stats", Finternal_stack_stats, S=
internal_stack_stats,
doc: /* internal */)
(void)
{
- struct bc_thread_state *bc =3D ¤t_thread->bc;
+ struct bc_thread_state *bc =3D current_thread->bc;
int nframes =3D 0;
int nruns =3D 0;
for (struct bc_frame *fp =3D bc->fp; fp; fp =3D fp->saved_fp)
@@ -474,7 +477,7 @@ exec_byte_code (Lisp_Object fun, ptrdiff_t args_templat=
e,
int volatile this_op =3D 0;
#endif
unsigned char quitcounter =3D 1;
- struct bc_thread_state *bc =3D ¤t_thread->bc;
+ struct bc_thread_state *bc =3D current_thread->bc;
=20
/* Values used for the first stack record when called from C. */
Lisp_Object *top =3D NULL;
@@ -983,7 +986,7 @@ #define DEFINE(name, value) [name] =3D &&insn_ ## name,
=09=09handlerlist =3D c->next;
=09=09top =3D c->bytecode_top;
=09=09op =3D c->bytecode_dest;
-=09=09bc =3D ¤t_thread->bc;
+=09=09bc =3D current_thread->bc;
=09=09struct bc_frame *fp =3D bc->fp;
=20
=09=09Lisp_Object fun =3D fp->fun;
diff --git a/src/igc.c b/src/igc.c
index b5666f7d1a6..0db1d1bf684 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -164,7 +164,7 @@
# ifndef HASH_Lisp_User_Ptr_7DC5544B44
# error "struct Lisp_User_Ptr changed"
# endif
-# ifndef HASH_thread_state_FFE7EECB29
+# ifndef HASH_thread_state_BB35177268
# error "struct thread_state changed"
# endif
# ifndef HASH_Lisp_Mutex_744F44A86D
@@ -924,6 +924,7 @@ IGC_DEFINE_LIST (igc_root);
/* Back pointer to Emacs' thread object. Allocated so that it doesn't
move in memory. */
struct thread_state *ts;
+ struct bc_thread_state *bc;
};
=20
typedef struct igc_thread igc_thread;
@@ -1647,7 +1648,7 @@ scan_bc (mps_ss_t ss, void *start, void *end, void *c=
losure)
MPS_SCAN_BEGIN (ss)
{
struct igc_thread_list *t =3D closure;
- struct bc_thread_state *bc =3D &t->d.ts->bc;
+ struct bc_thread_state *bc =3D t->d.bc;
igc_assert (start =3D=3D (void *) bc->stack);
igc_assert (end =3D=3D (void *) bc->stack_end);
/* FIXME/igc: AFAIU the current top frame starts at
@@ -3050,7 +3051,8 @@ root_create_specpdl (struct igc_thread_list *t)
root_create_bc (struct igc_thread_list *t)
{
struct igc *gc =3D t->d.gc;
- struct bc_thread_state *bc =3D &t->d.ts->bc;
+ struct bc_thread_state *bc =3D t->d.ts->bc;
+ t->d.bc =3D bc;
igc_assert (bc->stack !=3D NULL);
mps_root_t root;
mps_res_t res =3D mps_root_create_area (&root, gc->arena, mps_rank_ambig=
(), 0,
diff --git a/src/lisp.h b/src/lisp.h
index 391c5bef6e9..d3b95feeab9 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -5640,13 +5640,13 @@ #define DAEMON_RUNNING (w32_daemon_event !=3D INVAL=
ID_HANDLE_VALUE)
INLINE struct bc_frame *
get_act_rec (struct thread_state *th)
{
- return th->bc.fp;
+ return th->bc->fp;
}
=20
INLINE void
set_act_rec (struct thread_state *th, struct bc_frame *act_rec)
{
- th->bc.fp =3D act_rec;
+ th->bc->fp =3D act_rec;
}
=20
/* Defined in macros.c. */
diff --git a/src/thread.c b/src/thread.c
index ffb728a4822..9a9c2ecb5f4 100644
--- a/src/thread.c
+++ b/src/thread.c
@@ -687,7 +687,7 @@ mark_one_thread (struct thread_state *thread)
mark_object (tem);
}
=20
- mark_bytecode (&thread->bc);
+ mark_bytecode (thread->bc);
=20
/* No need to mark Lisp_Object members like m_last_thing_searched,
as mark_threads_callback does that by calling mark_object. */
@@ -895,7 +895,7 @@ finalize_one_thread (struct thread_state *state)
free_search_regs (&state->m_search_regs);
free_search_regs (&state->m_saved_search_regs);
sys_cond_destroy (&state->thread_condvar);
- free_bc_thread (&state->bc);
+ free_bc_thread (state->bc);
}
=20
DEFUN ("make-thread", Fmake_thread, Smake_thread, 1, 3, 0,
@@ -925,6 +925,7 @@ DEFUN ("make-thread", Fmake_thread, Smake_thread, 1, 3,=
0,
new_thread->name =3D name;
#ifdef HAVE_MPS
new_thread->m_getcjmp =3D igc_xzalloc_ambig (sizeof (*new_thread->m_getc=
jmp));
+ new_thread->bc =3D xzalloc (sizeof (*new_thread->bc));
#endif
/* Perhaps copy m_last_thing_searched from parent? */
new_thread->m_current_buffer =3D current_thread->m_current_buffer;
@@ -935,7 +936,7 @@ DEFUN ("make-thread", Fmake_thread, Smake_thread, 1, 3,=
0,
new_thread->m_specpdl_end =3D new_thread->m_specpdl + size;
new_thread->m_specpdl_ptr =3D new_thread->m_specpdl;
=20
- init_bc_thread (&new_thread->bc);
+ init_bc_thread (new_thread->bc);
sys_cond_init (&new_thread->thread_condvar);
=20
/* We'll need locking here eventually. */
@@ -1273,7 +1274,10 @@ init_threads (void)
=20
main_thread.s.thread_id =3D sys_thread_self ();
main_thread.s.buffer_disposition =3D Qnil;
- init_bc_thread (&main_thread.s.bc);
+#ifdef HAVE_MPS
+ main_thread.s.bc =3D xmalloc (sizeof (*main_thread.s.bc));
+#endif
+ init_bc_thread (main_thread.s.bc);
#ifdef HAVE_MPS
igc_on_alloc_main_thread_bc ();
#endif
diff --git a/src/thread.h b/src/thread.h
index f50a627cb33..41e3df14e3c 100644
--- a/src/thread.h
+++ b/src/thread.h
@@ -224,10 +224,12 @@ #define getcjmp (current_thread->m_getcjmp)
/* Threads are kept on a linked list. */
struct thread_state *next_thread;
=20
- struct bc_thread_state bc;
-
# ifdef HAVE_MPS
+ struct bc_thread_state *bc;
+
void *gc_info;
+# else
+ struct bc_thread_state bc[1];
# endif
=20
} GCALIGNED_STRUCT;
--=20
2.50.0
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 12 Oct 2025 20:14:43 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 16:14:43 2025 Received: from localhost ([127.0.0.1]:49963 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v82So-0007M5-TU for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 16:14:43 -0400 Received: from mail-ed1-x52e.google.com ([2a00:1450:4864:20::52e]:42278) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>) id 1v82Sm-0007LZ-61 for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 16:14:40 -0400 Received: by mail-ed1-x52e.google.com with SMTP id 4fb4d7f45d1cf-631df7b2dffso8082291a12.1 for <79584 <at> debbugs.gnu.org>; Sun, 12 Oct 2025 13:14:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760300074; x=1760904874; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=hCYBE+b2k5hFtmjvxvSac6UIbTWigi16YCCsw8SiNWs=; b=JCuDHpp06PwXDYY/oN7goCtZYb2RrUMvwtKWWxr5+QbLZcJau81YwUMhxUc5fZBeo+ tT5F9l5Ln7QKyZWhpSFTUIkEB15WkU8VQ1e0mwJx2by2sDLOHA/DG1OSDq862GfTdkI2 svoXawKor5jVPeNYUNI6Gc2SpJykOXtm+uUNQrTgJZWWobttTNhckZ4SQ751EDJxQhrm RJGfALeDDIic529WvqRhdmc5ZzgwuBXI7UrPhfWT1zOPErfrBi5kcrwKmMsF0XSuQUwl 2SK8Bin88yfBU0cqgTVoQCHFSET1mvhG54NtYT2FjGmhLHsfAop+UzoRTkhI9Za7Cpat 0PCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760300074; x=1760904874; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=hCYBE+b2k5hFtmjvxvSac6UIbTWigi16YCCsw8SiNWs=; b=FX2Scy6CNp+qY5Ck2AT2H1+TsIVRrVk1l/85Avns8Ijj9o20QUxwxkDLzkJj1C0rOY gmnii27WrQJPMnc9p4w0eREnvkD245Iq2ghAziqJrOmxBBCoN9RpoAv+boJ9xPNHwjpB lLMOsd7NNxZuXzeTRAwPpyAEncQEJzr1bUJ/Ga7sQcNRAUI0YKQdTUArZluKx02in1Pe mwW4QdV6wa6t/tF+R0NJVjS9u3KidJwlt4H9J7d0iYwLEco35lb939WLUH6NdMWk+XJm wc8Q/flZVfQv+qCIdOryO3Pa1mo0xlItkvICyUNK20InpMiAAg0rj6sRXptRYEs65i6S CyeA== X-Forwarded-Encrypted: i=1; AJvYcCVeN7Yn5n65YHpBMFFynCGviUGo8v/tYmMFU9zbqWJ5Scv/C0ICm1ntK+kD9Uei2rroB5M/Ww==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxRNIlZgQ/Dh6EUpl4nuClIKvdkEjaafZAqLheXuurTWerHVFjC ya0WeEUlIzpQr32C/+YVMmNsUXo5t+VZrtSAY7DoTb+0l5tpX8N17Vg3jJp/jQ== X-Gm-Gg: ASbGncv08OcnjsSmxb8axvingcDdMOSVeadO3RgV3dHD/aYDpHxfKYsWz0REen0q93X DTzWfhOGbgfUfrfnoSe6imAZJ99b0OXCxAUCeUnWox7zw8MtaNOk04D0eTvgOZ0Sq+4EB4Vq18w loBIBDH1VfCt3QuZ9zm2gFm/JFpjEoS9X0lwi+L9Jes9mbKCrB4DuzRlnm4knryti1VHisBA9mP EctDRKhOEPU4+A0XL5K5XFbcFxR6TFN8RzX82TpB+Zez7ECstx+zBbF18/DYeVBMMSRCI2mtRuO aY/sL+l6WAk/1JUfFtViRPGQ3qfkouZvQidTXCm9RPF4DmBLmtkYfBh4jQVjsli2ZmRQCi2hMn2 Ps97/xESxIwyM+p5EcR2pSrTCqTGotPtWKhnmzfuzUD/in08lAg== X-Google-Smtp-Source: AGHT+IFAVH6E+bBuFNCCcZkdERFgBH1PPTrYRadz1Qcwv3SsMPHXzU9RODgAbDT8CFRta6Hu9RqqpQ== X-Received: by 2002:a05:6402:1a4d:b0:639:db35:62df with SMTP id 4fb4d7f45d1cf-639db35684emr13154211a12.3.1760300073595; Sun, 12 Oct 2025 13:14:33 -0700 (PDT) Received: from caladan ([31.177.112.212]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-63a52b0f358sm7442567a12.10.2025.10.12.13.14.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Oct 2025 13:14:33 -0700 (PDT) From: Helmut Eller <eller.helmut@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <m2qzv7nbo9.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m2v7knnal7.fsf@HIDDEN> <87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN> <m2sefoicun.fsf@HIDDEN> <871pn8yrhh.fsf@HIDDEN> <m2o6qchs9e.fsf@HIDDEN> <87sefnylcc.fsf@HIDDEN> <m2qzv7nbo9.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Sun, 12 Oct 2025 22:14:32 +0200 Message-ID: <87ldlf7u8n.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: 79584 Cc: 79584 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>, oliver.reiter@HIDDEN, 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 (-) On Sun, Oct 12 2025, Gerd M=C3=B6llmann wrote: > Pip Cet <pipcet@HIDDEN> writes: > >> It adds what seems to me a large amount of infrastructure for managing >> "pins" and an ambiguously-scanned root of unlimited size,=20 > > Well, well. 50 loc and a root that is 64 words in reality... > >> and I'd prefer the much simpler fix I've described: An emacs_value is >> a fixnum which you look up in a hash table when you want the object, >> and it's removed from the hash table explicitly or (if it's negative) >> when the last environment goes out of scope. > > Plus something for thread_state, please. > > Anyway, I think I'll let you work now, and just merge what I can :-). I think for the time being we should use what Gerd has. Pip can then replace it or parts of it with his idea. So Gerd: please commit your patch. Helmut
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 12 Oct 2025 19:49:07 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 15:49:07 2025 Received: from localhost ([127.0.0.1]:49914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v8243-0005mm-3p for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 15:49:07 -0400 Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:61791) 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 1v823y-0005mF-RL for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 15:49:05 -0400 Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-46e42fa08e4so32136905e9.3 for <79584 <at> debbugs.gnu.org>; Sun, 12 Oct 2025 12:49:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760298536; x=1760903336; 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=GYLGo+nRz8aaz7OFuq6DF6hE1coyw/sbHdPkLzoTbBc=; b=BkqiDSTIC29e+Nwuse1uhKfYXx/XC0dIi51oNFlvvVGmdIOlODE6W07/EGTk53BE2q 4HrWrxyYWZjC0kvUq9j/sj8BTGWp72fsemjekkEzI0JaJldmohRxOCanxhkXEF2kwx4c UCHUdzlGJwq5ybXQaWVOvNaCoYAWGzwpA24t+FSVnEYGc9LFWOOFg6+N1nSQJYvmH72/ tm8+HMOJF9clih6InOo/9iBJbK8R2/x6guhgrJQMfrJ/mBBJtKKp255H5iT5Hl9JXYkV huTWYOSWeDcP7B4lnCPozh+mIsPldvBeC0bYSQeACzbjDYOnuwI7KUg7aZH2jYHZiG9Y mQQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760298536; x=1760903336; 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=GYLGo+nRz8aaz7OFuq6DF6hE1coyw/sbHdPkLzoTbBc=; b=aJ4QIZt/Z/61Ujt1Ph7oHAObGDrZtXGdGXQXDGSpp8TbJTrH31L31SoFTOl3BczZ7K tGn57oFlHcM7kGkJ+fdWcjkJwa5P7YYIqzWtMJlC7XEjHfU5kk/w4aKgCXvnGgYO+8JH Er+eJrKB5GrGj33eM/zsrs1+7nZ6gnGsnCLkEhyD6q7fKG6trhWy9SN5BzR95LymnyPX /QzhGUqSR3K0QqIMyhdc5koicKbigXFRtYFGllySEJFXvVOQ6LYyBxeYZEOlWlMQJ5yu pT5TLCFHeOP2u3k63LGU2KzDRUHGz39gUU8fdj6O+boP6ywP1WvbXlHD2LOZn0E4g0jF Nm7A== X-Forwarded-Encrypted: i=1; AJvYcCUS6hj2pKdKm5WRBZWAu+AumxEopAr2Zy+ev5XLSuFfdFxJqaog1g8Yeb1i7uERU+ckasSKhQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyD6slNU02PDxhnizL2q/f8YYJTziMu9UiG6jHqUrTvs4tb2vWx ejqcVyw3rs+erx2a0hbECNG9lIbgO94x2AsVIbNY/L/nPzhSD+nIosS27L7phw== X-Gm-Gg: ASbGncujc9JsA01GyFHTU/xA5u7WvsXC1V3Hn6oE3fPr3TZpDRFGulq4jiYwU3i8zbK +Cb4iTH+hkQ6W9dPekECfGHVPsh6eONNbE/yWKEaWzqyW+YG3xXmKlwD/cEYg/X4c0c1Rn2nfFm 4R9Z0HvW0NOzOB4WBHrBVYi33pZrsWN9vswcg+4H6M79oQB3MNrM7AoKqkeryqGKSmatksVIJ0f xwoID23V3YtKrRFyFgm93BN/M99HjGpq2GSGGcB1r4bXy9vu+PWxt73AjmAvJY4TEsI+LN1S9qT jP3bQjUmenGukNHDI76VkB/LoNoMsicu/xNAKPqX3Uu2a9K20hBAfA/tV7XX7Tm16+P4J/gSM8A 28bozog/VCBkN7MalOQPopWFh2KnYTq60Qk+MkmzaQqKH5jhjTCAdYhsL8BC/bqDM3qN+AiUbYX ciA2M0Ejp462l8gc6wqc3eLPdaSH+W+pD4o+6dYJ3hvJ7Ap/ZSRA== X-Google-Smtp-Source: AGHT+IG5l694wDHhgjS+mVZKi1l/W1RDzDb94TvaVPb9J23lfLufzuUeRTMAmvkvY5Jh8mQ+YpBc3A== X-Received: by 2002:a05:600c:3f08:b0:46e:4b42:1dbe with SMTP id 5b1f17b1804b1-46fa9b075f3mr138311735e9.32.1760298536192; Sun, 12 Oct 2025 12:48:56 -0700 (PDT) Received: from pro4 (p200300e0b730ea00f4ec76711c957195.dip0.t-ipconnect.de. [2003:e0:b730:ea00:f4ec:7671:1c95:7195]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-46fb489af92sm163174035e9.17.2025.10.12.12.48.54 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Oct 2025 12:48:55 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <87sefnylcc.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m2v7knnal7.fsf@HIDDEN> <87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN> <m2sefoicun.fsf@HIDDEN> <871pn8yrhh.fsf@HIDDEN> <m2o6qchs9e.fsf@HIDDEN> <87sefnylcc.fsf@HIDDEN> Date: Sun, 12 Oct 2025 21:48:54 +0200 Message-ID: <m2qzv7nbo9.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: 79584 Cc: oliver.reiter@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, Helmut Eller <eller.helmut@HIDDEN>, 79584 <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: > It adds what seems to me a large amount of infrastructure for managing > "pins" and an ambiguously-scanned root of unlimited size, Well, well. 50 loc and a root that is 64 words in reality... > and I'd prefer the much simpler fix I've described: An emacs_value is > a fixnum which you look up in a hash table when you want the object, > and it's removed from the hash table explicitly or (if it's negative) > when the last environment goes out of scope. Plus something for thread_state, please. Anyway, I think I'll let you work now, and just merge what I can :-).
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 12 Oct 2025 19:32:59 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 15:32:59 2025 Received: from localhost ([127.0.0.1]:49863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v81oR-0004lM-7j for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 15:32:59 -0400 Received: from mail-10628.protonmail.ch ([79.135.106.28]:62761) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1v81oO-0004l6-Qw for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 15:32:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1760297570; x=1760556770; bh=5gpm4jmHx2vpizDIsSrLMao2mTT2NevEb75pZxo1iPM=; 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; b=om7IK3v3m9L0XGCk79/MCSq5YY9YmYom6+d2dhZriQ33s2yxA1O+rfN6ps7lZn3jo ijA2nAjkwbeXY52rtYI/8qNDcPOh1IzceAAqBSNNrSupXRlNXnz88radzNyt/yk41B Ma/4QItUXSaxWbK/T3gsZvolPQ5cSQlNsjBKT9m7Flcb5KwsuBGe6evFLwW90Ve1BA maSLyiVftRRbPl3zJgzWbhI0KnTE8DpcMmMtT8wfG2kfeLhV4q8DSf/sZNa6z4RLkL yL6EPjKBgSbpEzE1Jd46V4jzj7CskCDgpnRsPovpp+M+hjEYpvIRHChy5kh/Vm0LXr +bxE2Lnmz4WgQ== Date: Sun, 12 Oct 2025 19:32:46 +0000 To: Helmut Eller <eller.helmut@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm Message-ID: <87ms5vyl1p.fsf@HIDDEN> In-Reply-To: <871pn87x30.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m2bjmg5omn.fsf@HIDDEN> <875xcnzzft.fsf@HIDDEN> <871pnbdhw8.fsf@HIDDEN> <877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN> <87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <871pn87x30.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: f3eaafbbbf5549f180a2a70fee943fc11e88858c 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: 79584 Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, oliver.reiter@HIDDEN, 79584 <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: -2.0 (--) "Helmut Eller" <eller.helmut@HIDDEN> writes: > On Sun, Oct 12 2025, Gerd M=C3=B6llmann wrote: > >> Please find attached the "final" version of what I have in my Emacs, >> ported to feature/igc. No further gymnastics needed for modules. I'd >> like to apply that, okay with you? > > I'm not sure. Removing the AMS pool seems like a good thing; for > performance reasons. I think we can agree to remove it; you dislike the performance, I dislike the lack of interior pointers, Gerd distrusts the code. No one's actually speaking up for AMS! > As Pip showed, implementing emacs_value without immovable objects is > quite feasible. And I think it's desirable. > I'm wondering if we could remove the immovable pool completely. Yes, please. > What to do with thread_state is not so clear to me. I don't quite see > why it has to be immovable. Has it to with the condition variable > thread_condvar? But then, why is Lisp_Condvar not immovable? I think it's the byte code state, which doesn't need to be immovable but cannot be behind a barrier. It doesn't sound like a big problem, to me, except testing it requires secondary Lisp threads and those are somewhat rare and difficult to work with. > If we only have thread_state objects in the immovable pool, then perhaps > it would easier to allocate thread_state with malloc and make it a > root. I'm not sure whether threads ever get finalized in ordinary operation, but if that isn't a problem, malloc sounds good to me here. Pip
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 12 Oct 2025 19:26:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 15:26:43 2025
Received: from localhost ([127.0.0.1]:49854 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v81iM-0004Ue-Uk
for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 15:26:43 -0400
Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335]:57581)
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 1v81iH-0004U7-Mh
for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 15:26:38 -0400
Received: by mail-wm1-x335.google.com with SMTP id
5b1f17b1804b1-46e37d10ed2so31812925e9.2
for <79584 <at> debbugs.gnu.org>; Sun, 12 Oct 2025 12:26:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1760297191; x=1760901991; 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=JEtoha++Xejd8X5JP9yX76kG6pZHgS/KimkEBlKMzfw=;
b=i1G1pMvYrsDinTA1R/jcwnbZUoNVo3E0fQG2ClPFddvwXX99Avpb44N1wcd4B7G02u
8PbOSD3QigWj4dpL0mw2qZXQPEwIvANrImdAeWJ0OSzYbHu0nc0kAZOlKVHu3o7pP0Os
cIvaeP5MFNb7nVuwUZHKiJGn6WX0y5nqWgbYSc5sQsiCD7+NaW7i5F4S86y8GLI7Prtn
82fMaL0xz+Q9BxJZv4hEwv5k6JfIIj4LAgzgtYyOalKlMp0gA9doaiOhYatEETnhH4/Z
RJQu/wOWPxD2rHsdtrryy6n5YLHtiTCwk3JAuIoXynwIX2uZIkBt4E0MVCeQzvKtNbED
x9/g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1760297191; x=1760901991;
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=JEtoha++Xejd8X5JP9yX76kG6pZHgS/KimkEBlKMzfw=;
b=k2FEzg0JXCSVBFC2n1UXkhuCLRNHAsNAqvRX0QnlkZrJCr09O66kTAt5cCoca+wyln
NHMvG9s5oc5UCmFAUUvkFkBplqox+Q0/g9DSI+DnPxK2iCZTU3xFku6mgBlrNt48dAnN
G7P3CF8QDWO00BfA94FMu/w/Q5wVp4tWXkFniuXlRHIcFFCglzoVwPPC3SGZoGxEODbS
hS1GNycheZsO0D22Brh6/LeUgYzWCw5QH8UEpzUGmQCxQ686etD5wEbDoJ0x5+J7oPxB
4xJKALoykOatf485DC2khbgWOgllPKmlYiaqlRtSKdQCT7iGd5flyz4U1M1eCeHLuYen
J6ig==
X-Forwarded-Encrypted: i=1;
AJvYcCW38UTH1+qAQEgGzA3E7FEnAq9NAGrNYaj0iN9xREC9Kfv1IpZEAoZtZsyUnFHHl+ukfj2+YQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzAtcH4hFcXC/VaVNIG6JITL3zQBeNFWDbtZBm7hVeZgeC1QPEo
c7B91yHIr9mJ9WNkQAPQdgo2Cb80xGxycoBCS/gDHl5wmtYkpO7WhuOKALDSzw==
X-Gm-Gg: ASbGncvgGrKTbKHfncP8vWba7EMkco4nm4T7YRI+ghrOz0BZB0lKl44JSoJMAR5inuc
z2k9rENhsgxWyVi85UH/2R8Gzq9qiI/QS/xigz6M2wupESNiPTv6bJO2mWJIfximRDlMNwYU3Yl
SqauNE3/JqudRp7jWCjtK70Ob6CP2owObgKf0mky0SZAz80Tqgxv7FiQ0/Suo7dRq/fgvKd/npm
DiNdqOkA35Y0qtLrB2F55gZt9ezbEFr88caT1L9Zav6kHYG2M8CO7QStMa4ySQxvbKFtfGliqn9
QfYpo6jJkAeGpcyu7VIbhZ4wqBEi3f2kJB1CGLwIUA2C/S3Bz779YL11q74ahIiE6ESQ9PDPA1d
E9uU2rbBKwS1+WxJbkcsc5GrsTdJScTJJnxMH8JClNd5V5wTBykbdlwYbH4ZQwVIZrnGJVX/Co/
N9o8uIePc2SuDLwizdf7N46CVbRktpNnbIVJxAvkv9+D0kKg6DVtokiN9j74g3
X-Google-Smtp-Source: AGHT+IHD6z8L+kurGG3rX1qXWftMzlwotZTrEusWN6p9Y7jZ285crCblGuMQe9fv27kv9hfU4pc5ag==
X-Received: by 2002:a05:600c:548d:b0:46e:49fd:5e30 with SMTP id
5b1f17b1804b1-46fa9a8f4e3mr136258955e9.6.1760297191004;
Sun, 12 Oct 2025 12:26:31 -0700 (PDT)
Received: from pro4 (p200300e0b730ea00f4ec76711c957195.dip0.t-ipconnect.de.
[2003:e0:b730:ea00:f4ec:7671:1c95:7195])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-46fb49bd977sm148663345e9.11.2025.10.12.12.26.30
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 12 Oct 2025 12:26:30 -0700 (PDT)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Helmut Eller <eller.helmut@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <871pn87x30.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
<87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN>
<87frbszhwn.fsf@HIDDEN> <87ikgoczj2.fsf@HIDDEN>
<m2frbs5www.fsf@HIDDEN> <m2bjmg5omn.fsf@HIDDEN>
<875xcnzzft.fsf@HIDDEN> <871pnbdhw8.fsf@HIDDEN>
<877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN>
<87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN>
<871pn87x30.fsf@HIDDEN>
Date: Sun, 12 Oct 2025 21:26:29 +0200
Message-ID: <m2v7kjncpm.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: 79584
Cc: 79584 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>,
oliver.reiter@HIDDEN, 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 (-)
Helmut Eller <eller.helmut@HIDDEN> writes:
> On Sun, Oct 12 2025, Gerd M=C3=B6llmann wrote:
>
>> Please find attached the "final" version of what I have in my Emacs,
>> ported to feature/igc. No further gymnastics needed for modules. I'd
>> like to apply that, okay with you?
>
> I'm not sure. Removing the AMS pool seems like a good thing; for
> performance reasons.
And don't forget interior pointers.
> As Pip showed, implementing emacs_value without immovable objects is
> quite feasible. And I think it's desirable.
Possibly.
> I'm wondering if we could remove the immovable pool completely.
I left it in just because. It could probably be removed, but it's also
not something costing much.
> What to do with thread_state is not so clear to me. I don't quite see
> why it has to be immovable. Has it to with the condition variable
> thread_condvar? But then, why is Lisp_Condvar not immovable?
The comment I left says
/* Alloc thread_state immovable because we need access to it for
scanning the bytecode stack (scan_bc), and making thread_state
immovable simplifies the code. */
One would have to check if that's still the case, but why wouldn't it,
and I'm admittedly much too lazy for that anyway :-).
> If we only have thread_state objects in the immovable pool, then perhaps
> it would easier to allocate thread_state with malloc and make it a
> root.
Please don't feel under pressure. I don't mind if my Emacs diverges from
GNU; it does in so many ways already, and it doesn't really matter
anyway :-).
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 12 Oct 2025 19:26:38 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 15:26:37 2025
Received: from localhost ([127.0.0.1]:49851 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v81iG-0004UL-AR
for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 15:26:37 -0400
Received: from mail-10629.protonmail.ch ([79.135.106.29]:35883)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1v81iC-0004U0-EK
for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 15:26:34 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1760297185; x=1760556385;
bh=6rAaZxgL37D0xY/mYKXywZHB4bJpUfNelQ4q6UaMR/8=;
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;
b=YFGR7qE0bs+x/G276RqLOztQPQlrSLmp8/hWYIKcp+HDW8fXbltN1kA98pSGUqVwj
4QDXdNvJzMdmoVrXY/pptuUlh651U0Blxg/qncRT2tV3u5F6GMSsI6CO//pvtcOvTO
ZcvOV/W89QdcA0zY0mQ1LfQncIdUzWrRkL4eSArYpJch+7pv23w0ngHT1yTiLAv+wN
URSIQnd9QngrY2A7WrFTxzVZL5oQ4sDxk5MWdT11hvG/oeUTUdEhzsqu+BXJIm2vBU
GFnJtRUQpLMIo/sOypFFS8Wu+JmQu9lsxHV4qb9VWJfTV8mJRuE3KWgknYaAWeFhi5
G6kBctvH2VhZA==
Date: Sun, 12 Oct 2025 19:26:22 +0000
To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
Message-ID: <87sefnylcc.fsf@HIDDEN>
In-Reply-To: <m2o6qchs9e.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <m2v7knnal7.fsf@HIDDEN>
<87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN>
<87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN>
<m2sefoicun.fsf@HIDDEN> <871pn8yrhh.fsf@HIDDEN>
<m2o6qchs9e.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: ae0a9dcdfa5877e9f349483093c5481be79ec423
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: 79584
Cc: oliver.reiter@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
Helmut Eller <eller.helmut@HIDDEN>, 79584 <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: -2.0 (--)
Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes:
> Pip Cet <pipcet@HIDDEN> writes:
>
>>>> It works on macOS at least, AFAICT, but I also don't remember 1 bit
>>>> about that subject, so maybe it doesn't work on other systems?
>>>
>>> Looking at thread_state, I see, as one would expect, it has Lisp_Object
>>> members. When one of these objects moves in memory, these references
>>> must be updated. So far so good and normal.
>>>
>>> How does this updating of references work, if thread_state does not hav=
e
>>> barriers?
>>
>> I'm very confused now, having run some experiments. The behavior I'm
>> observing is this:
>>
>> * when a trace starts, the AMS segments are unprotected. That's okay,
>> because MPS knows they're not reachable directly from the roots (all
>> reachability paths go through a barriered segment)
>
> I'm not sure, but I think you are talking specifically about the
> global_ref case? In that case, yes, we don't have roots referencing
> objects in AMS (ignoring that they might be referenced from the
> stack/registerds).
Indeed. So the module refs start out as white and unprotected, meaning
the data they contain is invalid but accessible. This is not a bug.
>
>> * symbols move, but the AMS segment remains unprotected.
>> * when you look at the AMC segment containing the Vmodule_refs_hash hash
>> table, MPS protects the AMS segment (????)
>
> IIRC, Helmut said that the ShieldExpose/Cover calls I've seen in the AMS
> pool scan (?) function had no effect because certain functions were not
> implemented by the AMS pool.
ShieldExpose/ShieldCover are indeed irrelevant here, it's the
ShieldRaise/ShieldLower in mutatorSegSetGrey that raises the barrier.
>> * when you access the AMS segment afterwards, you hit the barrier and
>> the reference gets fixed before you use it.
>
> AFAIR, you said and I think even showed, that you've seen the unfixed
> reference in the ANS object when accessing it through a direct reference
> to that AMS object, and that it was necessary to access the AMS object
> through a reference contained in an AMC object (the hash table in the
> case) because of that. Which I did not understand then, and which
> doesn't should not be the case given the above.
I stand by that theory, and it matches my observations, with the added
complexity that grey AMS segments are put behind read barriers, which
seems to contradict the documentation. I thought that grey objects would
simply be scanned eagerly as soon as they stopped being white and before
the mutator was allowed to continue.
>> Our problem, whether or not barriers are used, is that we accessed a
>> segment that was considered white, and I don't think that's okay whether
>> you're talking about AMS or AMC.
>>
>> I think.
>
> YYMV, but no place for AMS in my Emacs at least :-). I don't have the
I agree, we should get rid of AMS ASAP. I just think the replacement
should be as simple as possible, and fixing the module API seems to me
to fit that description. Introducing a "temporary" pinning API which we
don't actually need is a bit of a detour.
>>> My answer is that it can't, and if AMS hadn't falsely claimed
>>> to work with references to other pools, that would have been obvious
>>> from the start.
>>
>> AMS works with references to other pools to the same extent that AMC
>> does, AFAIU. You can't stash away a pointer to what used to be a valid
>> object in either pool, then dereference it, unless you tell MPS about
>> the pointer first.
>
> I was talking about the barriers. If what Helmut said is true, that the
> barriers are not effective because the AMS pool doesn't implement some
> functions, then I think there's no way they can work, IMO. And the docs
> say they don't use barriers which is an additional warning sign.
I think "no way they can work" is a bit strong, to be honest. An
unbarriered pool in a mostly-barriered arena makes perfect sense to me,
and there's no theoretical reason it can't work. In particular, that
white AMS segments are unprotected is not a bug.
>> So my proposal is to give up as far as possible on immovable objects and
>> huge ambiguous roots, whether on the stack or the heap.
>
> I'd vote for first making it work, then making it better :-). That is,
Works here :-)
> let's get rid of AMS in a first step. What I sent makes the global_ref
> case work fine without changes in the module case except a new member in
> global_ref which modules don't see.
It adds what seems to me a large amount of infrastructure for managing
"pins" and an ambiguously-scanned root of unlimited size, and I'd prefer
the much simpler fix I've described: An emacs_value is a fixnum which
you look up in a hash table when you want the object, and it's removed
from the hash table explicitly or (if it's negative) when the last
environment goes out of scope.
>>> IOW, I think if a requirement exists that thread_state must not have
>>> barriers, that must be solved differently. As I said, I don't remember
>>> such a requirement at all. Do you remember more, Pip?
>>
>> It seems AMS segments use barriers, but not at all times when we would
>> expect them to. If you need barrier-free memory, use xmalloc?
>
> I don't understand. It's not me who wants barrier-free thread_state. You
> mentioned a requirement to have no barriers on thread_state, which I
> don't remember having heard of.
I'm talking about this comment:
/* Alloc thread_state immovable because we need access to it for
=09 scanning the bytecode stack (scan_bc), and making thread_state
=09 immovable simplifies the code. */
I think that's still accurate: the BC state lives in struct
thread_state, which is allocated from MPS in the case of multiple
threads. So if a secondary thread ever runs bytecode it might hit a
barrier while in an MPS scanning function and crash.
And if I leave out the old non-MPS code entirely (which we can do since
the new code should work fine without !HAVE_MPS), I get
6 files changed, 57 insertions(+), 328 deletions(-)
diff --git a/src/data.c b/src/data.c
index db72529fb80..655403361d6 100644
--- a/src/data.c
+++ b/src/data.c
@@ -232,7 +232,6 @@ DEFUN ("cl-type-of", Fcl_type_of, Scl_type_of, 1, 1, 0,
/* WARNING!! Keep 'cl--type-hierarchy' in sync with this code!! */
switch (PSEUDOVECTOR_TYPE (XVECTOR (object)))
=09{
-=09case PVEC_MODULE_GLOBAL_REFERENCE: return Qmodule_global_reference;
case PVEC_NORMAL_VECTOR: return Qvector;
=09case PVEC_BIGNUM: return Qbignum;
=09case PVEC_MARKER: return Qmarker;
@@ -4210,7 +4209,6 @@ #define PUT_ERROR(sym, tail, msg)=09=09=09\
DEFSYM (Qcons, "cons");
DEFSYM (Qmarker, "marker");
DEFSYM (Qsymbol_with_pos, "symbol-with-pos");
- DEFSYM (Qmodule_global_reference, "module-global-reference");
DEFSYM (Qoverlay, "overlay");
DEFSYM (Qfinalizer, "finalizer");
DEFSYM (Qmodule_function, "module-function");
diff --git a/src/emacs-module.c b/src/emacs-module.c
index f3a92500f62..08f1126e690 100644
--- a/src/emacs-module.c
+++ b/src/emacs-module.c
@@ -132,14 +132,7 @@ Copyright (C) 2015-2025 Free Software Foundation, Inc.
/* A block from which `emacs_value' object can be allocated. */
struct emacs_value_frame
{
- /* Storage for values. */
- struct emacs_value_tag objects[value_frame_size];
-
- /* Index of the next free value in `objects'. */
- int offset;
-
- /* Pointer to next frame, if any. */
- struct emacs_value_frame *next;
+ char dummy;
};
=20
/* A structure that holds an initial frame (so that the first local
@@ -180,7 +173,6 @@ Copyright (C) 2015-2025 Free Software Foundation, Inc.
/* Forward declarations. */
=20
static Lisp_Object value_to_lisp (emacs_value);
-static emacs_value allocate_emacs_value (emacs_env *, Lisp_Object);
static emacs_value lisp_to_value (emacs_env *, Lisp_Object);
static enum emacs_funcall_exit module_non_local_exit_check (emacs_env *);
static void module_assert_thread (void);
@@ -198,8 +190,6 @@ Copyright (C) 2015-2025 Free Software Foundation, Inc.
=09=09=09=09=09 Lisp_Object, Lisp_Object);
static void module_out_of_memory (emacs_env *);
static void module_reset_handlerlist (struct handler *);
-static bool value_storage_contains_p (const struct emacs_value_storage *,
- emacs_value, ptrdiff_t *);
=20
static bool module_assertions =3D false;
=20
@@ -372,109 +362,44 @@ module_get_environment (struct emacs_runtime *runtim=
e)
return runtime->private_members->env;
}
=20
-/* To make global refs (GC-protected global values) keep a hash that
- maps global Lisp objects to 'struct module_global_reference'
- objects. We store the 'emacs_value' in the hash table so that it
- is automatically garbage-collected (Bug#42482). */
-
-static Lisp_Object Vmodule_refs_hash;
+static Lisp_Object module_objects_positive;
+static Lisp_Object module_objects_negative;
+static Lisp_Object Vmodule_objects;
=20
-static struct module_global_reference *
-XMODULE_GLOBAL_REFERENCE (Lisp_Object o)
+static Lisp_Object
+value_to_lisp (emacs_value value)
{
- eassert (PSEUDOVECTORP (o, PVEC_MODULE_GLOBAL_REFERENCE));
- return XUNTAG (o, Lisp_Vectorlike, struct module_global_reference);
+ return Fgethash (make_fixnum ((EMACS_INT) value), Vmodule_objects, Qnil)=
;
}
=20
-/* Returns whether V is a global reference. Only used to check module
- assertions. If V is not a global reference, increment *N by the
- number of global references (for debugging output). */
-
-static bool
-module_global_reference_p (emacs_value v, ptrdiff_t *n)
+static emacs_value
+lisp_to_value (emacs_env *env, Lisp_Object lisp_value)
{
- struct Lisp_Hash_Table *h =3D XHASH_TABLE (Vmodule_refs_hash);
- /* Note that we can't use `hash_find' because V might be a local
- reference that's identical to some global reference. */
- DOHASH (h, k, val)
- if (&XMODULE_GLOBAL_REFERENCE (val)->value =3D=3D v)
- return true;
- /* Only used for debugging, so we don't care about overflow, just
- make sure the operation is defined. */
- ckd_add (n, *n, h->count);
- return false;
+ Fputhash (module_objects_negative, lisp_value, Vmodule_objects);
+ if (!TYPE_RANGED_FIXNUMP (EMACS_INT, module_objects_negative))
+ eassume (0);
+ emacs_value ret =3D (void *) (EMACS_INT) XFIXNUM (module_objects_negativ=
e);
+ module_objects_negative =3D Fsub1 (module_objects_negative);
+ return ret;
}
=20
static emacs_value
module_make_global_ref (emacs_env *env, emacs_value value)
{
- MODULE_FUNCTION_BEGIN (NULL);
- struct Lisp_Hash_Table *h =3D XHASH_TABLE (Vmodule_refs_hash);
- Lisp_Object new_obj =3D value_to_lisp (value);
- hash_hash_t hashcode;
- ptrdiff_t i =3D hash_find_get_hash (h, new_obj, &hashcode);
-
- /* Note: This approach requires the garbage collector to never move
- objects. */
-
- if (i >=3D 0)
- {
- Lisp_Object value =3D HASH_VALUE (h, i);
- struct module_global_reference *ref =3D XMODULE_GLOBAL_REFERENCE (va=
lue);
- bool overflow =3D ckd_add (&ref->refcount, ref->refcount, 1);
- if (overflow)
-=09overflow_error ();
- MODULE_INTERNAL_CLEANUP ();
- return &ref->value;
- }
- else
- {
-#ifdef HAVE_MPS
- struct module_global_reference *ref =3D igc_alloc_global_ref ();
-#else
- struct module_global_reference *ref
- =3D ALLOCATE_PLAIN_PSEUDOVECTOR (struct module_global_reference,
- PVEC_MODULE_GLOBAL_REFERENCE);
-#endif
- ref->value.v =3D new_obj;
- ref->refcount =3D 1;
- Lisp_Object value;
- XSETPSEUDOVECTOR (value, ref, PVEC_MODULE_GLOBAL_REFERENCE);
- hash_put (h, new_obj, value, hashcode);
- MODULE_INTERNAL_CLEANUP ();
- return &ref->value;
- }
+ Lisp_Object lisp_value =3D value_to_lisp (value);
+ Fputhash (module_objects_positive, lisp_value, Vmodule_objects);
+ if (!TYPE_RANGED_FIXNUMP (EMACS_INT, module_objects_negative))
+ eassume (0);
+ emacs_value ret =3D (void *) (EMACS_INT) XFIXNUM (module_objects_positiv=
e);
+ module_objects_positive =3D Fadd1 (module_objects_positive);
+ return ret;
}
=20
static void
module_free_global_ref (emacs_env *env, emacs_value global_value)
{
- /* TODO: This probably never signals. */
- /* FIXME: Wait a minute. Shouldn't this function report an error if
- the hash lookup fails? */
- MODULE_FUNCTION_BEGIN ();
- struct Lisp_Hash_Table *h =3D XHASH_TABLE (Vmodule_refs_hash);
- Lisp_Object obj =3D value_to_lisp (global_value);
- ptrdiff_t i =3D hash_find (h, obj);
-
- if (module_assertions)
- {
- ptrdiff_t n =3D 0;
- if (! module_global_reference_p (global_value, &n))
- module_abort ("Global value was not found in list of %"pD"d global=
s",
- n);
- }
-
- if (i >=3D 0)
- {
- Lisp_Object value =3D HASH_VALUE (h, i);
- struct module_global_reference *ref =3D XMODULE_GLOBAL_REFERENCE (va=
lue);
- eassert (0 < ref->refcount);
- if (--ref->refcount =3D=3D 0)
- hash_remove_from_table (h, obj);
- }
-
- MODULE_INTERNAL_CLEANUP ();
+ EMACS_INT integer =3D (EMACS_INT) global_value;
+ Fremhash (make_int (integer), Vmodule_objects);
}
=20
static enum emacs_funcall_exit
@@ -493,8 +418,8 @@ module_non_local_exit_clear (emacs_env *env)
env->private_members->pending_non_local_exit =3D emacs_funcall_exit_retu=
rn;
}
=20
-static struct emacs_value_tag module_out_of_memory_symbol;
-static struct emacs_value_tag module_out_of_memory_data;
+#define module_out_of_memory_symbol (*(emacs_value) (EMACS_INT) 1)
+#define module_out_of_memory_data (*(emacs_value) (EMACS_INT) 2)
=20
static enum emacs_funcall_exit
module_non_local_exit_get (emacs_env *env,
@@ -507,9 +432,9 @@ module_non_local_exit_get (emacs_env *env,
if (ret !=3D emacs_funcall_exit_return)
{
emacs_value sym
-=09=3D allocate_emacs_value (env, p->non_local_exit_symbol);
+=09=3D module_make_global_ref (env, lisp_to_value (env, p->non_local_exit_=
symbol));
emacs_value dat
-=09=3D allocate_emacs_value (env, p->non_local_exit_data);
+=09=3D module_make_global_ref (env, lisp_to_value (env, p->non_local_exit_=
data));
if (sym =3D=3D NULL || dat =3D=3D NULL)
=09{
=09 sym =3D &module_out_of_memory_symbol;
@@ -1286,7 +1211,7 @@ funcall_module (Lisp_Object function, ptrdiff_t nargs=
, Lisp_Object *arglist)
{
args[i] =3D lisp_to_value (env, arglist[i]);
if (! args[i])
-=09memory_full (sizeof *args[i]);
+=09memory_full (sizeof args[i]);
}
=20
/* The only possibility of getting an error until here is failure to
@@ -1418,141 +1343,11 @@ module_out_of_memory (emacs_env *env)
=09=09=09=09 XCDR (Vmemory_signal_data));
}
=20
-
-/* Value conversion. */
-
-/* Convert an `emacs_value' to the corresponding internal object.
- Never fails. */
-
-/* If V was computed from lisp_to_value (O), then return O.
- Exits non-locally only if the stack overflows. */
-static Lisp_Object
-value_to_lisp (emacs_value v)
-{
- if (module_assertions)
- {
- /* Check the liveness of the value by iterating over all live
- environments. */
- ptrdiff_t num_environments =3D 0;
- ptrdiff_t num_values =3D 0;
- for (const union specbinding *pdl =3D specpdl; pdl !=3D specpdl_ptr;=
++pdl)
- if (pdl->kind =3D=3D SPECPDL_MODULE_ENVIRONMENT)
- {
- const emacs_env *env =3D pdl->unwind_ptr.arg;
- struct emacs_env_private *priv =3D env->private_members;
- if (value_storage_contains_p (&priv->storage, v, &num_values))
- goto ok;
- ++num_environments;
- }
- /* Also check global values. */
- if (module_global_reference_p (v, &num_values))
- goto ok;
- module_abort (("Emacs value not found in %"pD"d values "
-=09=09 "of %"pD"d environments"),
- num_values, num_environments);
- }
-
- ok: return v->v;
-}
-
-/* Convert an internal object to an `emacs_value'. Allocate storage
- from the environment; return NULL if allocation fails. */
-static emacs_value
-lisp_to_value (emacs_env *env, Lisp_Object o)
-{
- struct emacs_env_private *p =3D env->private_members;
- if (p->pending_non_local_exit !=3D emacs_funcall_exit_return)
- return NULL;
- return allocate_emacs_value (env, o);
-}
-
-/* Must be called for each frame before it can be used for allocation. */
-static void
-initialize_frame (struct emacs_value_frame *frame)
-{
- frame->offset =3D 0;
- frame->next =3D NULL;
-}
-
-/* Must be called for any storage object before it can be used for
- allocation. */
-static void
-initialize_storage (struct emacs_value_storage *storage)
-{
- initialize_frame (&storage->initial);
- storage->current =3D &storage->initial;
-}
-
-/* Must be called for any initialized storage object before its
- lifetime ends. Free all dynamically-allocated frames. */
-static void
-finalize_storage (struct emacs_value_storage *storage)
-{
- struct emacs_value_frame *next =3D storage->initial.next;
- while (next !=3D NULL)
- {
- struct emacs_value_frame *current =3D next;
- next =3D current->next;
-#ifdef HAVE_MPS
- igc_destroy_root_with_start (current);
-#endif
- free (current);
- }
-}
-
-/* Allocate a new value from STORAGE and stores OBJ in it. Return
- NULL if allocation fails and use ENV for non local exit reporting. */
-static emacs_value
-allocate_emacs_value (emacs_env *env, Lisp_Object obj)
-{
- struct emacs_value_storage *storage =3D &env->private_members->storage;
- eassert (storage->current);
- eassert (storage->current->offset < value_frame_size);
- eassert (! storage->current->next);
- if (storage->current->offset =3D=3D value_frame_size - 1)
- {
- storage->current->next =3D malloc (sizeof *storage->current->next);
- if (! storage->current->next)
- {
- module_out_of_memory (env);
- return NULL;
- }
-#ifdef HAVE_MPS
- {
-=09char *start =3D (char *) storage->current->next;
-=09char *end =3D start + sizeof *storage->current->next;
-=09igc_root_create_ambig (start, end, "emacs_value_frame");
- }
-#endif
- initialize_frame (storage->current->next);
- storage->current =3D storage->current->next;
- }
- emacs_value value =3D storage->current->objects + storage->current->offs=
et;
- value->v =3D obj;
- ++storage->current->offset;
- return value;
-}
-
-#ifndef HAVE_MPS
-/* Mark all objects allocated from local environments so that they
- don't get garbage-collected. */
-void
-mark_module_environment (void *ptr)
-{
- emacs_env *env =3D ptr;
- struct emacs_env_private *priv =3D env->private_members;
- mark_object (priv->non_local_exit_symbol);
- mark_object (priv->non_local_exit_data);
- for (struct emacs_value_frame *frame =3D &priv->storage.initial; frame !=
=3D NULL;
- frame =3D frame->next)
- for (int i =3D 0; i < frame->offset; ++i)
- mark_object (frame->objects[i].v);
-}
-#endif // not HAVE_MPS
-
=20
/* Environment lifetime management. */
=20
+static ptrdiff_t live_envs;
+
/* Must be called before the environment can be used. Returns another
pointer that callers should use instead of the ENV argument. If
module assertions are disabled, the return value is ENV. If module
@@ -1571,7 +1366,6 @@ initialize_environment (emacs_env *env, struct emacs_=
env_private *priv)
priv->pending_non_local_exit =3D emacs_funcall_exit_return;
priv->non_local_exit_symbol =3D Qnil;
priv->non_local_exit_data =3D Qnil;
- initialize_storage (&priv->storage);
env->size =3D sizeof *env;
env->private_members =3D priv;
env->make_global_ref =3D module_make_global_ref;
@@ -1612,6 +1406,7 @@ initialize_environment (emacs_env *env, struct emacs_=
env_private *priv)
env->open_channel =3D module_open_channel;
env->make_interactive =3D module_make_interactive;
env->make_unibyte_string =3D module_make_unibyte_string;
+ live_envs++;
return env;
}
=20
@@ -1620,7 +1415,20 @@ initialize_environment (emacs_env *env, struct emacs=
_env_private *priv)
static void
finalize_environment (emacs_env *env)
{
- finalize_storage (&env->private_members->storage);
+ live_envs--;
+ if (live_envs =3D=3D 0 && !FIXNATP (CALLN (Fplus,
+=09=09=09=09=09 module_objects_negative,
+=09=09=09=09=09 module_objects_positive,
+=09=09=09=09=09 make_fixnum (512))))
+ {
+ Lisp_Object new_hash =3D
+=09make_hash_table (&hashtest_eq, DEFAULT_HASH_SIZE, Weak_None);
+ DOHASH (XHASH_TABLE (Vmodule_objects), k, v)
+=09if (FIXNATP (k))
+=09 Fputhash (k, v, new_hash);
+ Vmodule_objects =3D new_hash;
+ module_objects_negative =3D make_fixnum (-1);
+ }
}
=20
void
@@ -1678,26 +1486,6 @@ init_module_assertions (bool enable)
module_assertions =3D enable;
}
=20
-/* Return whether STORAGE contains VALUE. Used to check module
- assertions. Increment *COUNT by the number of values searched. */
-
-static bool
-value_storage_contains_p (const struct emacs_value_storage *storage,
- emacs_value value, ptrdiff_t *count)
-{
- for (const struct emacs_value_frame *frame =3D &storage->initial; frame =
!=3D NULL;
- frame =3D frame->next)
- {
- for (int i =3D 0; i < frame->offset; ++i)
- {
- if (&frame->objects[i] =3D=3D value)
- return true;
- ++*count;
- }
- }
- return false;
-}
-
static AVOID ATTRIBUTE_FORMAT_PRINTF (1, 2)
module_abort (const char *format, ...)
{
@@ -1717,9 +1505,13 @@ module_abort (const char *format, ...)
void
syms_of_module (void)
{
- staticpro (&Vmodule_refs_hash);
- Vmodule_refs_hash
+ staticpro (&Vmodule_objects);
+ Vmodule_objects
=3D make_hash_table (&hashtest_eq, DEFAULT_HASH_SIZE, Weak_None);
+ staticpro (&module_objects_positive);
+ module_objects_positive =3D make_fixnum (1);
+ staticpro (&module_objects_negative);
+ module_objects_negative =3D make_fixnum (-1);
=20
DEFSYM (Qmodule_out_of_memory, "module-out-of-memory");
Fput (Qmodule_out_of_memory, Qerror_conditions,
@@ -1727,11 +1519,8 @@ syms_of_module (void)
Fput (Qmodule_out_of_memory, Qerror_message,
=09build_unibyte_string ("Module out of memory"));
=20
- staticpro (&module_out_of_memory_symbol.v);
- module_out_of_memory_symbol.v =3D Qmodule_out_of_memory;
-
- staticpro (&module_out_of_memory_data.v);
- module_out_of_memory_data.v =3D Qnil;
+ module_make_global_ref (NULL, lisp_to_value (NULL, Qmodule_out_of_memory=
));
+ module_make_global_ref (NULL, lisp_to_value (NULL, Qnil));
=20
DEFSYM (Qmodule_load_failed, "module-load-failed");
Fput (Qmodule_load_failed, Qerror_conditions,
diff --git a/src/igc.c b/src/igc.c
index b5666f7d1a6..c30dbad06da 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -206,9 +206,6 @@
# ifndef HASH_Lisp_Obarray_29CFFD1B74
# error "struct Lisp_Obarray changed"
# endif
-# ifndef HASH_module_global_reference_85FFC23A88
-# error "struct module_global_reference changed"
-# endif
# ifndef HASH_Lisp_TS_Parser_66A8E2974E
# error "struct Lisp_TS_Parser changed"
# endif
@@ -495,7 +492,6 @@ obj_type_name (enum igc_obj_type type)
"PVEC_MUTEX",
"PVEC_CONDVAR",
"PVEC_MODULE_FUNCTION",
- "PVEC_MODULE_GLOBAL_REFERENCE",
"PVEC_NATIVE_COMP_UNIT",
"PVEC_TS_PARSER",
"PVEC_TS_NODE",
@@ -2716,20 +2712,6 @@ fix_xwidget_view (mps_ss_t ss, struct xwidget_view *=
v)
=20
#endif // HAVE_XWIDGETS
=20
-#ifdef HAVE_MODULES
-static mps_res_t
-fix_global_ref (mps_ss_t ss, struct module_global_reference *r)
-{
- MPS_SCAN_BEGIN (ss)
- {
- IGC_FIX_CALL_FN (ss, struct Lisp_Vector, r, fix_vectorlike);
- IGC_FIX12_OBJ (ss, &r->value.v);
- }
- MPS_SCAN_END (ss);
- return MPS_RES_OK;
-}
-#endif
-
#ifndef IN_MY_FORK
static mps_res_t
fix_obarray (mps_ss_t ss, struct Lisp_Obarray *o)
@@ -2863,12 +2845,6 @@ fix_vector (mps_ss_t ss, struct Lisp_Vector *v)
=09IGC_FIX_CALL_FN (ss, struct Lisp_Native_Comp_Unit, v, fix_comp_unit);
=09break;
=20
- case PVEC_MODULE_GLOBAL_REFERENCE:
-#ifdef HAVE_MODULES
-=09IGC_FIX_CALL_FN (ss, struct module_global_reference, v, fix_global_ref)=
;
-#endif
-=09break;
-
case PVEC_TS_PARSER:
#ifdef HAVE_TREE_SITTER
=09IGC_FIX_CALL_FN (ss, struct Lisp_TS_Parser, v, fix_ts_parser);
@@ -3810,7 +3786,6 @@ finalize_vector (mps_addr_t v)
case PVEC_XWIDGET_VIEW:
case PVEC_TERMINAL:
case PVEC_MARKER:
- case PVEC_MODULE_GLOBAL_REFERENCE:
igc_assert (!"finalization not implemented");
break;
=20
@@ -3922,7 +3897,6 @@ maybe_finalize (mps_addr_t client, enum pvec_type tag=
)
#ifdef IN_MY_FORK
case PVEC_PACKAGE:
#endif
- case PVEC_MODULE_GLOBAL_REFERENCE:
break;
}
}
@@ -4312,18 +4286,6 @@ alloc_immovable (size_t size, enum igc_obj_type type=
)
return alloc_impl (size, type, t->d.immovable_ap);
}
=20
-#ifdef HAVE_MODULES
-void *
-igc_alloc_global_ref (void)
-{
- size_t nwords_mem =3D VECSIZE (struct module_global_reference);
- struct Lisp_Vector *v
- =3D alloc_immovable (header_size + nwords_mem * word_size, IGC_OBJ_VEC=
TOR);
- XSETPVECTYPESIZE (v, PVEC_MODULE_GLOBAL_REFERENCE, 0, nwords_mem);
- return v;
-}
-#endif
-
Lisp_Object
igc_make_cons (Lisp_Object car, Lisp_Object cdr)
{
diff --git a/src/lisp.h b/src/lisp.h
index 391c5bef6e9..5ff828edcb4 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -1061,7 +1061,6 @@ DEFINE_GDB_SYMBOL_END (PSEUDOVECTOR_FLAG)
PVEC_MUTEX,
PVEC_CONDVAR,
PVEC_MODULE_FUNCTION,
- PVEC_MODULE_GLOBAL_REFERENCE,
PVEC_NATIVE_COMP_UNIT,
PVEC_TS_PARSER,
PVEC_TS_NODE,
@@ -6343,26 +6342,9 @@ maybe_gc (void)
=20
# ifdef HAVE_MODULES
=20
-/* An `emacs_value' is just a pointer to a structure holding an
- internal Lisp object. */
-struct emacs_value_tag { Lisp_Object v; };
-
-/* Pseudovector type for global references. The pseudovector tag is
- PVEC_OTHER since these values are never printed and don't need to
- be special-cased for garbage collection. */
-
-struct module_global_reference
-{
- /* Pseudovector header, must come first. */
- struct vectorlike_header header;
-
- /* Holds the emacs_value for the object. The Lisp_Object stored
- therein must be the same as the hash key. */
- struct emacs_value_tag value;
-
- /* Reference count, always positive. */
- ptrdiff_t refcount;
-};
+/* An `emacs_value' is just a pointer to an structure deliberately left
+ undefined, like a Lisp_Object is. */
+struct emacs_value_tag;
=20
# endif /* HAVE_MODULES */
=20
diff --git a/src/pdumper.c b/src/pdumper.c
index 952f5876f79..d4790e47093 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -3236,7 +3236,6 @@ dump_vectorlike (struct dump_context *ctx,
case PVEC_CONDVAR:
case PVEC_SQLITE:
case PVEC_MODULE_FUNCTION:
- case PVEC_MODULE_GLOBAL_REFERENCE:
case PVEC_SYMBOL_WITH_POS:
case PVEC_FREE:
case PVEC_TS_PARSER:
diff --git a/src/print.c b/src/print.c
index c0da81a8703..5b223a6d17b 100644
--- a/src/print.c
+++ b/src/print.c
@@ -2232,7 +2232,6 @@ print_vectorlike_unreadable (Lisp_Object obj, bool es=
capeflag, char *buf,
/* Impossible cases. */
case PVEC_FREE:
case PVEC_OTHER:
- case PVEC_MODULE_GLOBAL_REFERENCE:
break;
}
emacs_abort ();
Pip
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 12 Oct 2025 19:13:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 15:13:18 2025 Received: from localhost ([127.0.0.1]:49833 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v81VO-0003sO-E4 for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 15:13:18 -0400 Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]:59818) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>) id 1v81VL-0003s5-1Q for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 15:13:16 -0400 Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-62fca01f0d9so7287381a12.3 for <79584 <at> debbugs.gnu.org>; Sun, 12 Oct 2025 12:13:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760296389; x=1760901189; 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=+ZNpfrCsh5JX89Daew1fWNyKfc9wpbwMVY9N8gEpPVY=; b=TybK7ZdNSksStUfhPMsXhNrff+YAACsbqahGF9PTzJHD9+uTLA2s8TAhpARGL5c7OI /IvwJWCv/3VnlZGYpwKpeWQIsreaAmIAVS6A3cYqKm3SAevzzeyOXTpx18fkibsYHyCk TJogRaX4q7kPlAfup5l/KJBsWXIjuFTJx4COVogUtK9RXtbpgPgFgumwxt12TON/65Z0 jmwgzLgxF0vSz5e8ve7JiC+Tbt87PwNQRS2JJht7e/LEyFEjRP1MGJT5gabUNLbhf/TI 5uf+QwggoQ1PdzkNsyASPgsXXeN2dNcGFYVxSXgCnBJLNznjqtBskB0KDhFpqSz6QTg/ hDBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760296389; x=1760901189; 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=+ZNpfrCsh5JX89Daew1fWNyKfc9wpbwMVY9N8gEpPVY=; b=c5e1gKvKfcjSLHfuDiYkCvLJVFQxxWBoQknLMX41bOzxYvC3NQnrxmpsw04C52oCq5 6Bhisd56ZJKo6FxB9mwZ9x84qgWg2q6o+Z5CUZUH8tVrSCfKk0OJRgMO00/S/z5vaYsi NP9LA0A4uq0dSMhSu5O3WYjIOXM8NM7yEKirqYF1Z5+fAdnxmOONsReoTjUK0wgdTjtR tPWKQiSTcU3wclcjlrQpicQ6Gv82f/9Ne+iwSDzKFngur0Ihql652jdNekHPPoIOKiTg SItArgcQyU0oqg7URGcKytPrqfG4ImAWU9q561tfYijPv4/z2bGQm8cLQttKT2GtOGm+ qxpw== X-Forwarded-Encrypted: i=1; AJvYcCVCapTFjt3tt5sp/Mvciyo8hS2MgWNAC6GTdz9ZmLuy4EAO9nGim0igrsLZzAH8FroUcqm8nA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxdG7GtlIyOP5EdHmzEr42r5hN+sjnaAkDn8nOnuuIb/y7024do 3Q+4s6V1IVoXPimpEvNz+yz3jqVWp05sp+PttfL/m9cn5tKc4m7rA8huq+Ss+A== X-Gm-Gg: ASbGncuRq+jLAshaPVYFuKUoHe9mGLYCY+tKTwhN5LQD5cHfjwPhfjlAe52qssJlKTI IHKuYtNAiAIZRFX24KEGif931o21Frus3vjOnxriA9oLLPtdHy9FNy0TgYWZEYhjWR+kWM33vgg 0mHIRWDBsSfsuLop1Hy6WEcY9uwfRZxby+pyGNgc/Iuu7p3rtFh9QRBdFvpzoE+ryu9ez2g5OYl H2+wGZpseU9yiQqksgWnWzYVLZfyDP+4gIBoQKUJL59rM0LmsRpqKHRiWjyq1B3YVx/olbRWhus feIzd3FeeaOINTJfaGLy93q7HJ+pw9xeR5PfrEFDt3wiB3YjYvB7NwKxzS1aI+UjkAR13E1oYzB mK9lpv6KmDkba4+adJnDj+DUB3Oo0/rzfEsuBRkwM3KtrcXoSdH/STYjhwvP2 X-Google-Smtp-Source: AGHT+IHRdSh0ll6fh3jhefs1v6ynRAFwAnrA231Btui18k/BFx3EDocqwWJEsEGwuTSSPyfwjmgV7Q== X-Received: by 2002:aa7:d859:0:b0:62f:386d:aedb with SMTP id 4fb4d7f45d1cf-639d5c75ccbmr12420948a12.36.1760296388460; Sun, 12 Oct 2025 12:13:08 -0700 (PDT) Received: from caladan ([31.177.112.212]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-63a5235e7ebsm7312483a12.1.2025.10.12.12.13.07 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Oct 2025 12:13:07 -0700 (PDT) From: Helmut Eller <eller.helmut@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <m21pn8jvy2.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m21pndpqtv.fsf@HIDDEN> <87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN> <87frbszhwn.fsf@HIDDEN> <87ikgoczj2.fsf@HIDDEN> <m2frbs5www.fsf@HIDDEN> <m2bjmg5omn.fsf@HIDDEN> <875xcnzzft.fsf@HIDDEN> <871pnbdhw8.fsf@HIDDEN> <877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN> <87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> Date: Sun, 12 Oct 2025 21:13:07 +0200 Message-ID: <871pn87x30.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: 79584 Cc: 79584 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>, oliver.reiter@HIDDEN, 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 (-) On Sun, Oct 12 2025, Gerd M=C3=B6llmann wrote: > Please find attached the "final" version of what I have in my Emacs, > ported to feature/igc. No further gymnastics needed for modules. I'd > like to apply that, okay with you? I'm not sure. Removing the AMS pool seems like a good thing; for performance reasons. As Pip showed, implementing emacs_value without immovable objects is quite feasible. And I think it's desirable. I'm wondering if we could remove the immovable pool completely. What to do with thread_state is not so clear to me. I don't quite see why it has to be immovable. Has it to with the condition variable thread_condvar? But then, why is Lisp_Condvar not immovable? If we only have thread_state objects in the immovable pool, then perhaps it would easier to allocate thread_state with malloc and make it a root. Helmut
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 12 Oct 2025 18:47:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 14:47:20 2025 Received: from localhost ([127.0.0.1]:49729 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v816G-0001Ym-BC for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 14:47:20 -0400 Received: from mail-wm1-x32c.google.com ([2a00:1450:4864:20::32c]:47334) 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 1v816D-0001YH-SA for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 14:47:18 -0400 Received: by mail-wm1-x32c.google.com with SMTP id 5b1f17b1804b1-46e34052bb7so43054305e9.2 for <79584 <at> debbugs.gnu.org>; Sun, 12 Oct 2025 11:47:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760294831; x=1760899631; 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=+ylnIhDJ6A1408jNqPI/uSlLlbTtZT4IcT2aEIBUG14=; b=blojMt3k4D4UfJfFPRwzt9pVaiKjlomCXiBvRaNsjyEGiCsPANvsC3POaambZiHrGO TLAu3d1zEnRWsP6RmE4KkwAxWvHCQmo0E07wzdgcB1D2zVwjp5bGx5MvWKmCw6e3TEtC 6b1Uo49kdsK9JsRVcu1F8gwz5ofI2aFnqwGosB9FTWo7jG32w2e23bhdRBtDiOaK0YPT Xqb3jpBmHoWPcBoveNNHQOZc3mL2kY6vKjba21m+abMil5VBym9Jkznxt/gmAXZK6kma ap3rs9spd3vq4DiFWTkMqKh03EIa0HkPHqWTvbX7fEzpO2GcwQ83b1lOOe2l3XfwKoSV YAHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760294831; x=1760899631; 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=+ylnIhDJ6A1408jNqPI/uSlLlbTtZT4IcT2aEIBUG14=; b=BsQhN0NeeuqF+pSca1u0qMGdZUX+gVj+UgjcIKaN9p79NuW8lOBWjJdkA0bN2BGQNC YRlhG9P/1uU68AUULBkW+j0wEaws+XSgRBuBvqF9W37dFpk2eWDh9eATSeiop02P1dRY +nDldAyox3KwRnJOO2r8Hg7HTsoz6WDmcCtyKF/0pEVCnG0t74dAy/Bw9y4Crs7Iv5AE rMbuDAiqSWAeXNXB9MFDaoSk9U0UFa3CFpGKX3AIaGmefVXVy38u95WJbiEasQGIL/76 yNFMv1nN09+hqeMmcEunnLqUbRcEU5KwZ6urb/0ihDDiUZ3BnO0ua7y01qwTkHYfHDu+ sx1A== X-Forwarded-Encrypted: i=1; AJvYcCUmw14P1fdbSGH5Dh66Zq64AWh9rzB6aWxNb3nRdhRbRqGzrT4cnOiZipIjgQxcsV2C+o/RSg==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yxo0/hqrVzaFOpCd1XMuZ3toWv0GpJoQl87NNEELFdMk5q5mmL/ 62tGOaW9uDR2TRBOoMBUcKJbR6DGyy6stoh9UyPSbSLlh9LcycZLP2OadxCLhA== X-Gm-Gg: ASbGncukNn4KffnkIhFiSwSuScQSL1fhbCeVxDyCCFKgg3uabU+gQXDQ/5SJe6HJ9ly U4qkA0XK2wWvfI4uHcn04+vSXVlPJdZrTNGU8oDyYasU8L7DaHIx681J3ARoCHMq2KTj/ObpOD7 tMXAj4Sw8sw/7H3aqH8tsauZhS+Js5EHt7BvlFrh6AvKwdVgnHS+ROhrTuLXV3OUuoMaDw0qZbw P7jrstaVWc+zzIRcdee0YgHN2BsoEAUgxfdzkl5pgmyhkdysy2nizPB7OqxTlO0a98OyytUqZ4U XJa423MHKPah/jn6kivUUzOXX2z6bNTpjeb8WNFNgdXucPVdnWFLIj3y3TX8BMof4ZlPsKL5tBx KQ35dvw5y8LsUKDGKAskoL1Ycp11kOffWlYYmSjKbO1IxFuuTpXIh12fO8HbVy7H1ULgaTkYYNN PVQP7/yOU/nL9Kl8wayfcVXmUZAQv11FG4j5ZsPhPA7g09/FuqjIRDE9sazdDX X-Google-Smtp-Source: AGHT+IFafy7CQ0eNkANden6HygExcL7uM9qIpQtFpXsxOmv3Dee7/yPdgphnm3FIRCpJwHTGDCgQVg== X-Received: by 2002:a05:6000:603:b0:407:77f9:949e with SMTP id ffacd0b85a97d-42666ac7026mr11380462f8f.21.1760294830998; Sun, 12 Oct 2025 11:47:10 -0700 (PDT) Received: from pro4 (p200300e0b730ea00f4ec76711c957195.dip0.t-ipconnect.de. [2003:e0:b730:ea00:f4ec:7671:1c95:7195]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-426ce57d3desm14461470f8f.7.2025.10.12.11.47.09 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Oct 2025 11:47:10 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <871pn8yrhh.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <871pnbdhw8.fsf@HIDDEN> <877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN> <87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN> <m2sefoicun.fsf@HIDDEN> <871pn8yrhh.fsf@HIDDEN> Date: Sun, 12 Oct 2025 20:47:09 +0200 Message-ID: <m2o6qchs9e.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: 79584 Cc: oliver.reiter@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, Helmut Eller <eller.helmut@HIDDEN>, 79584 <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: >>> It works on macOS at least, AFAICT, but I also don't remember 1 bit >>> about that subject, so maybe it doesn't work on other systems? >> >> Looking at thread_state, I see, as one would expect, it has Lisp_Object >> members. When one of these objects moves in memory, these references >> must be updated. So far so good and normal. >> >> How does this updating of references work, if thread_state does not have >> barriers? > > I'm very confused now, having run some experiments. The behavior I'm > observing is this: > > * when a trace starts, the AMS segments are unprotected. That's okay, > because MPS knows they're not reachable directly from the roots (all > reachability paths go through a barriered segment) I'm not sure, but I think you are talking specifically about the global_ref case? In that case, yes, we don't have roots referencing objects in AMS (ignoring that they might be referenced from the stack/registerds). > * symbols move, but the AMS segment remains unprotected. > * when you look at the AMC segment containing the Vmodule_refs_hash hash > table, MPS protects the AMS segment (????) IIRC, Helmut said that the ShieldExpose/Cover calls I've seen in the AMS pool scan (?) function had no effect because certain functions were not implemented by the AMS pool. > * when you access the AMS segment afterwards, you hit the barrier and > the reference gets fixed before you use it. AFAIR, you said and I think even showed, that you've seen the unfixed reference in the ANS object when accessing it through a direct reference to that AMS object, and that it was necessary to access the AMS object through a reference contained in an AMC object (the hash table in the case) because of that. Which I did not understand then, and which doesn't should not be the case given the above. > I think this is rather confusing, particularly the step labelled (????). > AMS is documented not to have barriers, but AMSSeg inherits from > MutatorSeg, which installs barriers (as observed) when the segment > becomes grey. Like I said, I personally distrust AMS deeply :-/. And when Helmut found that the rank stuff doesn't work, that distrust even deepened. > Our problem, whether or not barriers are used, is that we accessed a > segment that was considered white, and I don't think that's okay whether > you're talking about AMS or AMC. > > I think. YYMV, but no place for AMS in my Emacs at least :-). I don't have the patience for deciphering something like AMS when I know a working alternative exists that is known to work in other circumstances :-). >> My answer is that it can't, and if AMS hadn't falsely claimed >> to work with references to other pools, that would have been obvious >> from the start. > > AMS works with references to other pools to the same extent that AMC > does, AFAIU. You can't stash away a pointer to what used to be a valid > object in either pool, then dereference it, unless you tell MPS about > the pointer first. I was talking about the barriers. If what Helmut said is true, that the barriers are not effective because the AMS pool doesn't implement some functions, then I think there's no way they can work, IMO. And the docs say they don't use barriers which is an additional warning sign. > But the other limitations of AMS make it a bad choice: we need ambiguous > interior pointers keeping objects alive. Yes, that's another concerning point. > So my proposal is to give up as far as possible on immovable objects and > huge ambiguous roots, whether on the stack or the heap. I'd vote for first making it work, then making it better :-). That is, let's get rid of AMS in a first step. What I sent makes the global_ref case work fine without changes in the module case except a new member in global_ref which modules don't see. Then improve on that by reducing immovable objects if we can/want/have the time. > Here's my idea: [...] Sorry for snipping out your idea. It's not because I find the ideas bad (haven't looked), but because I think removing AMS is more important at this point, plus it solves the bug that has been reported, plus it also solves potential problems with thread_state. >> IOW, I think if a requirement exists that thread_state must not have >> barriers, that must be solved differently. As I said, I don't remember >> such a requirement at all. Do you remember more, Pip? > > It seems AMS segments use barriers, but not at all times when we would > expect them to. If you need barrier-free memory, use xmalloc? I don't understand. It's not me who wants barrier-free thread_state. You mentioned a requirement to have no barriers on thread_state, which I don't remember having heard of.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 12 Oct 2025 17:13:58 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 13:13:58 2025 Received: from localhost ([127.0.0.1]:49491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v7zds-0004sg-T8 for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 13:13:57 -0400 Received: from mail-24416.protonmail.ch ([109.224.244.16]:11883) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1v7zdp-0004sD-Iq for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 13:13:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1760289226; x=1760548426; bh=edieDZPTabPq+HcajDFzLRM0OGmmPREchMHpBD5TKBM=; 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; b=PNbx91HxxXsotRrQa08neYtkSlFwoGMRTjQuYxsK5GkFZqb2mRw/5ectj1ECBhCJu I+97JW/W1Iko9rR/joEY/12osEoZTkwxvrBDOzyC3d3S627/HpHdy7/LbBNDmtB2rM aXTGkQZyraNSAYXElgQ24k+a0gGtGCNCS4s3GxgHPaXe17Ju4X0I61yQBggVyYQ+ky 4moN0Orh2FStSsE6SNjpIwjPYEwtfymv75AsBGItMhaPA8jJk4fjdPPZgf7C2/ijHw E+bwSQrZrYqLS3817SPDSnD+Q7Yug1NEkHhwRWA3GKo6fInXi1EpDgTTg0gHP4e1ja i2Xc748TROVrA== Date: Sun, 12 Oct 2025 17:13:43 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm Message-ID: <871pn8yrhh.fsf@HIDDEN> In-Reply-To: <m2sefoicun.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <871pnbdhw8.fsf@HIDDEN> <877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN> <87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN> <m2sefoicun.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 00323ef36a9d3710a0352a12643f5b0d1135e462 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: 79584 Cc: oliver.reiter@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, Helmut Eller <eller.helmut@HIDDEN>, 79584 <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: -2.0 (--) Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: > >> Pip Cet <pipcet@HIDDEN> writes: >> >>> Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: >>> >>>> Helmut Eller <eller.helmut@HIDDEN> writes: >>>> >>>>> On Thu, Oct 09 2025, Gerd M=C3=B6llmann wrote: >>>>> >>>>>>> It would mean that all objects referenced by the AMS pool are pinne= d. >>>>>>> Which could be useful. >>>>>> >>>>>> Who makes sure that objects in AMS get scanned and pin referenced >>>>>> objects? How does MPS detect when references in AMS objects change w= hen >>>>>> there are no barriers? Ans so on. >>>>> >>>>> It looks like it's not implemented. I added the MPS_KEY_RANK argumen= t, >>>>> but then (require 'vterm) triggers this assertion: >>>>> >>>>> #5 traceFindGrey (segReturn=3D<synthetic pointer>, >>>>> rankReturn=3D<synthetic pointer>, arena=3D0x7ffff7fbe000, ti=3D0) >>>>> at ../mps/code/trace.c:1103 >>>>> 1103=09 AVER(RingIsSingle(ArenaGreyRing(arena, RankAMBIG))); >>>>> >>>>> Disappointing. >>>> >>>> Please find attached the "final" version of what I have in my Emacs, >>>> ported to feature/igc. No further gymnastics needed for modules. I'd >>>> like to apply that, okay with you? >>> >>> Does this work with the PVEC_THREAD allocation? The reason for using >>> alloc_immovable there was to avoid barriers, and now we're allocating >>> from a pool which does have barriers. >>> >> >> It works on macOS at least, AFAICT, but I also don't remember 1 bit >> about that subject, so maybe it doesn't work on other systems? > > Looking at thread_state, I see, as one would expect, it has Lisp_Object > members. When one of these objects moves in memory, these references > must be updated. So far so good and normal. > > How does this updating of references work, if thread_state does not have > barriers? I'm very confused now, having run some experiments. The behavior I'm observing is this: * when a trace starts, the AMS segments are unprotected. That's okay, because MPS knows they're not reachable directly from the roots (all reachability paths go through a barriered segment) * symbols move, but the AMS segment remains unprotected. * when you look at the AMC segment containing the Vmodule_refs_hash hash table, MPS protects the AMS segment (????) * when you access the AMS segment afterwards, you hit the barrier and the reference gets fixed before you use it. I think this is rather confusing, particularly the step labelled (????). AMS is documented not to have barriers, but AMSSeg inherits from MutatorSeg, which installs barriers (as observed) when the segment becomes grey. Our problem, whether or not barriers are used, is that we accessed a segment that was considered white, and I don't think that's okay whether you're talking about AMS or AMC. I think. > My answer is that it can't, and if AMS hadn't falsely claimed > to work with references to other pools, that would have been obvious > from the start. AMS works with references to other pools to the same extent that AMC does, AFAIU. You can't stash away a pointer to what used to be a valid object in either pool, then dereference it, unless you tell MPS about the pointer first. But the other limitations of AMS make it a bad choice: we need ambiguous interior pointers keeping objects alive. So my proposal is to give up as far as possible on immovable objects and huge ambiguous roots, whether on the stack or the heap. Here's my idea: An emacs_value is a hash index (if we want to keep it a pointer, we can either cast an integer to a pointer or make it a pointer to an integer on the heap somewhere, or assume LISP_WORDS_ARE_POINTERS and simply cast a fixnum to emacs_value). If the index is positive, the object is global, and has to be recycled explicitly. If the index is negative, the object can go away as soon as the environment it's in dies; in practice, I believe it's probably sufficient to recycle such objects once the last local environment goes out of scope, and only if there are too many such references or debugging is enabled. No immovable objects. No refcounting. A simple single index-to-object hash table, which gets rebuilt (and thus shrunk) when it's convenient (all module environments went out of scope). If there are problems with long-lived module environments (or multiple independent module environments making it so we never reach the "all module environments are dead" point), we can deal with that complication. Let's burn that bridge when we come to it. Plenty of silly possible optimizations, of course, but do we need to deal with those? I suspect not. But just to be on the sure side, let's modify the documented module API in this way: 1. If you obtain an emacs_value from module_make_global_ref, you can do with it what you want: it can live in registers, on the stack, on the heap, and you can even serialize it (send it over the network or save it to disk) and unserialize it back to an emacs_value if you must for some reason do so. But you must free it when done or it's Emacs (not your module) which leaks valuable memory and slows down other modules. 2. If you obtain an emacs_value elsewhere, you must treat it as a potentially GCable object. You can keep it on the stack (or in a register, which compilers give you no control over these days), but you can't store it on the heap, obfuscate or munge it, serialize it, etc. If you must do so, you need to turn it into a global ref and free it when done. 3. There is no guarantee that identical objects have identical emacs_values, not even if you try to create the same global ref twice. 4. While emacs_value will usually "look like" a pointer, we make no guarantees about its alignedness, tag bits, or anything else. > IOW, I think if a requirement exists that thread_state must not have > barriers, that must be solved differently. As I said, I don't remember > such a requirement at all. Do you remember more, Pip? It seems AMS segments use barriers, but not at all times when we would expect them to. If you need barrier-free memory, use xmalloc? I'd really like to unify emacs_value (as used by modules) with the opaque pointer required by other callbacks. I think these days, everyone uses void * for opaque pointers, and void * is equivalent to a pointer to an undeclared struct on all current systems, so there's no binary incompatibility, even if the C magic is unsatisfactory. If we want high performance, we should: 1. make the pointer word representing a Lisp value use tag 1 (or another nonzero tag) 2. choose a pseudorandom starting point integer when we start Emacs, so conservative GC can recognize such pointers with some certainty. 3. (possibly) make it so when we rebuild the hash table, positively-numbered Lisp_Objects appear at their hash index, which would save us a hash lookup once in a while. Pip
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 12 Oct 2025 11:22:36 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 07:22:36 2025 Received: from localhost ([127.0.0.1]:47946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v7u9s-0007NN-4N for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 07:22:36 -0400 Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:60420) 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 1v7u9o-0007Mm-IE for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 07:22:34 -0400 Received: by mail-wm1-x334.google.com with SMTP id 5b1f17b1804b1-46e42deffa8so30804585e9.0 for <79584 <at> debbugs.gnu.org>; Sun, 12 Oct 2025 04:22:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760268146; x=1760872946; 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=82Nf3W4WroMGqh5rOTM0/nvopdc0zNctmHNfTVoQAbs=; b=i6LMPt9wgzNEPC1ojvwLxRQCgYdKrSB0qIMNhM1MNNDA/MOVlaiAteSnqLhuJol1FA egNz7RAuiEoVRgzrvTqJCRJ+iei29lypWy4Da8ltQfjB1nPn+Tvk0xgCUDS45ynqz5aH fxNsKT3viy9onQzGajXe6ON+1VNmXHVRjkXIZBz1CXGPG8ZdTOmFRC0wFFxmgs4IgGOC ZgiSw+4Iva3kUgLIFm1HJDtu0dB+Y6NWLdNAKjP+JL0XkQn9Aw9zBd8Rd4yYxiCNbPuz JOw4q+Lx1bEnbEvLJZGoucxVjr1vS5qgEdg25Dyai8LHDYODufP3cK5/C1E3CVHJpTrd o9lQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760268146; x=1760872946; 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=82Nf3W4WroMGqh5rOTM0/nvopdc0zNctmHNfTVoQAbs=; b=Uni0dLgXlLOGCvz5bRnrhQlfMuA8LYRLZg9qxeyXw5EfJqIZKQrDNnBM3jvAppsehj afUjNcoPz2bwsM66IWsA8Vty310yAAsYC1WMnNf+Uw402lZQaHlC4vHtQ4ndauVDN18U uW/FnpIO5YTqPB6r80yPxsXmt9G67v9HMs3Cciv4BlLQgL3qNv4YoiwQQPg0wHA7daKQ RfvxiE++5slDXk4Qdkb7rJ0fAZanWkU3LE9gaBDk3M7q6K2hv/inceIG7zNSAFeqgpG4 z0fZ6UIXp94DsqXB9IoVZOBcZIcBRoRIWnsmEG2xzI9NHYLxJYAgKN/Nv0/N0hAMCC99 Lt4Q== X-Forwarded-Encrypted: i=1; AJvYcCX4oeKJ9y/VGHvNdlMneyB0WX5RVMV/vqSGOOgZtUl2a8sHWFk0ZRwrp1hO9EMKb4ZHBUWzqw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzNttE7xVpylTpN96cm9v3kMtHvnZMV1T2e0OkfFyeLbWCFEbmC uWQfCEhB0pGKn5asCPK9PUwFUrc0lz69uEhOV5si9tE4PhZFcSddzEROZTw2bw== X-Gm-Gg: ASbGncvRdpjsLQc8Tzduwkg1uFRfjnT2veg4xB1fk+yzOYXOL817ZGCGVp3eIjdEH4x oevXBq30ODnaG41CGih6BUUw2djQk538p6V/muueT9LfIQ1mJlM7zIGaSBNB7ff6GxQ3g7fokQA 2uNxKoxTj5wSk0NFAhqmLSxWAE8TqdIF2QgTmkRArF0G2oTVeE3T3GGLi2n/Nd6J22QvY8aN3X8 WeKR+afAL7WLY8y6lXZmucp8AJnu/10Fit1+pbW3LvEFbr5nN0LKS+9ofBZGrt2eKzW5Vc0ra3f XyCavLhXb+wmWdRAiA8iUYj+tNFU4dfpNEYOh9qxh5zCfzJD/uBVF2hkh0fnQC2q2jNL1ERoVCR l2OpxU9Z/s8oCHsfhZzTe9GfaIi97bK9/H7uzGVP1XJmLUvv5isPLImnOZpO4Y96woyGgy1YFVm 1G0AvJzmVVOCf69tHynyrGj8Ip++EzJh152ZqJBvbD9kDkp5KBpTIgszKmdGiB X-Google-Smtp-Source: AGHT+IHcs0cOi05UM9Fbgma7niU154vEO9TbhRbzMyogeNs+TqcLSi42QzteALTTeYcx/ksMCIPseQ== X-Received: by 2002:a05:600c:608d:b0:46e:6d5f:f59 with SMTP id 5b1f17b1804b1-46fa9a8b2aemr116244615e9.4.1760268145454; Sun, 12 Oct 2025 04:22:25 -0700 (PDT) Received: from pro4 (p200300e0b730ea00f4ec76711c957195.dip0.t-ipconnect.de. [2003:e0:b730:ea00:f4ec:7671:1c95:7195]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-46fb49d159csm130794905e9.20.2025.10.12.04.22.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Oct 2025 04:22:24 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <m2wm50ig2j.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m2frbs5www.fsf@HIDDEN> <m2bjmg5omn.fsf@HIDDEN> <875xcnzzft.fsf@HIDDEN> <871pnbdhw8.fsf@HIDDEN> <877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN> <87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN> <m2wm50ig2j.fsf@HIDDEN> Date: Sun, 12 Oct 2025 13:22:24 +0200 Message-ID: <m2sefoicun.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: 79584 Cc: oliver.reiter@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, Helmut Eller <eller.helmut@HIDDEN>, 79584 <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: >> >>> Helmut Eller <eller.helmut@HIDDEN> writes: >>> >>>> On Thu, Oct 09 2025, Gerd M=C3=B6llmann wrote: >>>> >>>>>> It would mean that all objects referenced by the AMS pool are pinned. >>>>>> Which could be useful. >>>>> >>>>> Who makes sure that objects in AMS get scanned and pin referenced >>>>> objects? How does MPS detect when references in AMS objects change wh= en >>>>> there are no barriers? Ans so on. >>>> >>>> It looks like it's not implemented. I added the MPS_KEY_RANK argument, >>>> but then (require 'vterm) triggers this assertion: >>>> >>>> #5 traceFindGrey (segReturn=3D<synthetic pointer>, >>>> rankReturn=3D<synthetic pointer>, arena=3D0x7ffff7fbe000, ti=3D0) >>>> at ../mps/code/trace.c:1103 >>>> 1103 AVER(RingIsSingle(ArenaGreyRing(arena, RankAMBIG))); >>>> >>>> Disappointing. >>> >>> Please find attached the "final" version of what I have in my Emacs, >>> ported to feature/igc. No further gymnastics needed for modules. I'd >>> like to apply that, okay with you? >> >> Does this work with the PVEC_THREAD allocation? The reason for using >> alloc_immovable there was to avoid barriers, and now we're allocating >> from a pool which does have barriers. >> > > It works on macOS at least, AFAICT, but I also don't remember 1 bit > about that subject, so maybe it doesn't work on other systems? Looking at thread_state, I see, as one would expect, it has Lisp_Object members. When one of these objects moves in memory, these references must be updated. So far so good and normal. How does this updating of references work, if thread_state does not have barriers? My answer is that it can't, and if AMS hadn't falsely claimed to work with references to other pools, that would have been obvious from the start. IOW, I think if a requirement exists that thread_state must not have barriers, that must be solved differently. As I said, I don't remember such a requirement at all. Do you remember more, Pip?
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 12 Oct 2025 10:13:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 06:13:03 2025 Received: from localhost ([127.0.0.1]:47831 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v7t4Y-00011e-Mh for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 06:13:03 -0400 Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:51257) 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 1v7t4W-00010y-He for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 06:13:01 -0400 Received: by mail-wr1-x42a.google.com with SMTP id ffacd0b85a97d-421b93ee372so1721151f8f.2 for <79584 <at> debbugs.gnu.org>; Sun, 12 Oct 2025 03:13:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760263974; x=1760868774; 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=MlkoyFbL0y5sGuWphb+zwc+zBOj5wKevdDBjUnhJrEE=; b=WCvkSujkGIltoWN2xczVXR4rX3DD1AWdjhatUILsHG+gWmE9aosXaSBPvC6/SKACCs gFKVpxdENnYur1agYjucegWb7+QlXVEu01kuO/KEMhRnCIPu5E7M6m/z2LP82Z6B/nQj cXl27bUkpyDPzLgLtNbFOiq+KoBOoZ5G59m10VG0VALC3OEJmZ9rjr6jfRjIADWN1wmQ hi2ey3pM3aKwGMk1GqzD+HQ2mwH5lipgqDmUl91nzFmc8RcCDzyVC70lvICEKlyg8Xyi eNv9vMgixE70qbKg8Z9x2wDtZ4PmaOFSUnPi8LwqQzLGLoTJPzsx8vt7w4kRGdlSZyeI gaKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760263974; x=1760868774; 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=MlkoyFbL0y5sGuWphb+zwc+zBOj5wKevdDBjUnhJrEE=; b=SFoMY1NwJ1sYC1cnI2RNmzlMPIx7eDWW7S9KiE4Ks0400/NwjhZe40EO5U9Page/iw 3YyuU9XeQgE53K5fDV/S7SM0lKG+j30qKI6M3w6h8uCh0Rc20EvRtYAs9uvGSz8FpAE4 mw/+8R+tgaQfolg4ZAhARRLSTyI9qbYBIQnqMxq/CG0WkDo9B1AKAvCatD0myint4fMl fLnKF+YV4HBBlzXt9j2JyfzeRu/JCESBwwtCnfPmz/hAMe+qaaWsawPchdXyWJPWOyMH xlTHJV7lBQ6CQ+EKd8f1fg8Bs1Pc01Flr4+uQmOqo+N3v80zkTfBVkpjUpEBsxqQTXeT 13rg== X-Forwarded-Encrypted: i=1; AJvYcCX+mFeRanZ76gG65cAKapXHL2u0rez/jiIBrd3JCBoIEM1toLQskOMbWV1vY7bJb8XKjNF59w==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyhcAd7iuv+e2BtCag6S6BJE0hmyCfKyjJnMX84WgNhh8+UP9kg 7THOMmViusfW1Hex62rsCIN4y0wAM0v8IfIe2tUV5F6GavTnKp0Ix6zJpvfI7w== X-Gm-Gg: ASbGncuYaA8yufaDyI6ssyDCB9USWMtB1mWfVPsmElXWmxJlIbY0dL+HAJScoiILG/+ 11ANk+K7ZLrosGKA6zNAd36QNTzCnqeJ0P7QbHu14q/eORHTpxN7xj1OE2E1DSOFJ2BKFR91Mys YHPX7vos5dhbH2rqdgsSHgSVcgvQJubxu7jUWDnxf9gLWrvyNZqu4rOsqTMbr0FW1tYPzGpUxU+ 0BgZyZE79X/s0KoozpGXnvGj8vplPYBh+TDBED2f8neG7131fqueAqPj37JWDnaGjFTGVsNCK4c 7UoLDRqJUtGxubSMt2wxZvygf09UliLxbhHTvqFbzoakmKeEgK1AcAw5fl2kkiO836zRroi0MmH Tv+p/AP/NXr8NqFD4t1eLQVvUBeOxfEEwQ+kBA6BLc3i25+Q3hNZVikwqgONe1oqZttbWky7Rx6 38UMretzKB5JN3jHd4T5CFpDTbYBTTTCuWWR/FQ9SIXBS7KW4jHQ== X-Google-Smtp-Source: AGHT+IGw4Ghuud5z5uCJqnST5V1EECZC/8G2hCpxRATaSwpvmX9oneXZwdLL220oA/NXr2YsZ0FCiw== X-Received: by 2002:a05:6000:3105:b0:3f9:1571:fdea with SMTP id ffacd0b85a97d-4266e8dd683mr12580459f8f.44.1760263973764; Sun, 12 Oct 2025 03:12:53 -0700 (PDT) Received: from pro4 (p200300e0b730ea00f4ec76711c957195.dip0.t-ipconnect.de. [2003:e0:b730:ea00:f4ec:7671:1c95:7195]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-426ce5dfc43sm12382408f8f.36.2025.10.12.03.12.52 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Oct 2025 03:12:53 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <87bjmca0y5.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m2frbs5www.fsf@HIDDEN> <m2bjmg5omn.fsf@HIDDEN> <875xcnzzft.fsf@HIDDEN> <871pnbdhw8.fsf@HIDDEN> <877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN> <87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> <87bjmca0y5.fsf@HIDDEN> Date: Sun, 12 Oct 2025 12:12:52 +0200 Message-ID: <m2wm50ig2j.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: 79584 Cc: oliver.reiter@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, Helmut Eller <eller.helmut@HIDDEN>, 79584 <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: > >> Helmut Eller <eller.helmut@HIDDEN> writes: >> >>> On Thu, Oct 09 2025, Gerd M=C3=B6llmann wrote: >>> >>>>> It would mean that all objects referenced by the AMS pool are pinned. >>>>> Which could be useful. >>>> >>>> Who makes sure that objects in AMS get scanned and pin referenced >>>> objects? How does MPS detect when references in AMS objects change when >>>> there are no barriers? Ans so on. >>> >>> It looks like it's not implemented. I added the MPS_KEY_RANK argument, >>> but then (require 'vterm) triggers this assertion: >>> >>> #5 traceFindGrey (segReturn=3D<synthetic pointer>, >>> rankReturn=3D<synthetic pointer>, arena=3D0x7ffff7fbe000, ti=3D0) >>> at ../mps/code/trace.c:1103 >>> 1103 AVER(RingIsSingle(ArenaGreyRing(arena, RankAMBIG))); >>> >>> Disappointing. >> >> Please find attached the "final" version of what I have in my Emacs, >> ported to feature/igc. No further gymnastics needed for modules. I'd >> like to apply that, okay with you? > > Does this work with the PVEC_THREAD allocation? The reason for using > alloc_immovable there was to avoid barriers, and now we're allocating > from a pool which does have barriers. > It works on macOS at least, AFAICT, but I also don't remember 1 bit about that subject, so maybe it doesn't work on other systems?
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 12 Oct 2025 10:08:44 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 06:08:43 2025 Received: from localhost ([127.0.0.1]:47824 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v7t0N-0000mb-KC for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 06:08:43 -0400 Received: from mail-4316.protonmail.ch ([185.70.43.16]:51257) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1v7t0L-0000mK-40 for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 06:08:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1760263714; x=1760522914; bh=kLQChrOYp6gbtRYlWz2c78XQXQemWazvMmXwEfTqgJY=; 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; b=Ndj+ZzeB3tkts2dsaZMFC08DdcpvJXQdFu+vqzqkrWDdUcz0VJl1tLrbtbd9aZhVm XX8WeeQ9HNFYEizbU79GAyuK0zFt9TnzU0WGG7z4fA2/ZKIogGq6duiTc4k6YUiPMK VbiowuhWft4KeKOwM9s8Cc7x9O+oWxD7F77GAYWxO3vfSMwXWmItRIsNyZTvIX5hFx g3QQQlFTE+ht1RBZG7LiEg5R4XkYXRM4ExCUvZwdCqEJ3I/S0LtZqPMwbOaRGFk71X rTyCPjdHBjTQ6tqJEnWa9fHG/2cN7AUZ7Y5qVQBev1lbAUCcGZ00aPJxuLuiSlCmVP UxKKpQnrQ/myw== Date: Sun, 12 Oct 2025 10:08:30 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm Message-ID: <87bjmca0y5.fsf@HIDDEN> In-Reply-To: <m21pn8jvy2.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m2frbs5www.fsf@HIDDEN> <m2bjmg5omn.fsf@HIDDEN> <875xcnzzft.fsf@HIDDEN> <871pnbdhw8.fsf@HIDDEN> <877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN> <87347rxo57.fsf@HIDDEN> <m21pn8jvy2.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 9baee343964403e8eed7a0db579504b3c0fae65b 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: 79584 Cc: oliver.reiter@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, Helmut Eller <eller.helmut@HIDDEN>, 79584 <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: > Helmut Eller <eller.helmut@HIDDEN> writes: > >> On Thu, Oct 09 2025, Gerd M=C3=B6llmann wrote: >> >>>> It would mean that all objects referenced by the AMS pool are pinned. >>>> Which could be useful. >>> >>> Who makes sure that objects in AMS get scanned and pin referenced >>> objects? How does MPS detect when references in AMS objects change when >>> there are no barriers? Ans so on. >> >> It looks like it's not implemented. I added the MPS_KEY_RANK argument, >> but then (require 'vterm) triggers this assertion: >> >> #5 traceFindGrey (segReturn=3D<synthetic pointer>, >> rankReturn=3D<synthetic pointer>, arena=3D0x7ffff7fbe000, ti=3D0) >> at ../mps/code/trace.c:1103 >> 1103=09 AVER(RingIsSingle(ArenaGreyRing(arena, RankAMBIG))); >> >> Disappointing. > > Please find attached the "final" version of what I have in my Emacs, > ported to feature/igc. No further gymnastics needed for modules. I'd > like to apply that, okay with you? Does this work with the PVEC_THREAD allocation? The reason for using alloc_immovable there was to avoid barriers, and now we're allocating from a pool which does have barriers. Pip
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 12 Oct 2025 09:44:49 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Oct 12 05:44:49 2025
Received: from localhost ([127.0.0.1]:47782 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v7sdE-00087m-IR
for submit <at> debbugs.gnu.org; Sun, 12 Oct 2025 05:44:49 -0400
Received: from mail-wm1-x32d.google.com ([2a00:1450:4864:20::32d]:46410)
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 1v7sdC-00087Y-BK
for 79584 <at> debbugs.gnu.org; Sun, 12 Oct 2025 05:44:47 -0400
Received: by mail-wm1-x32d.google.com with SMTP id
5b1f17b1804b1-46b303f755aso27393675e9.1
for <79584 <at> debbugs.gnu.org>; Sun, 12 Oct 2025 02:44:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1760262279; x=1760867079; 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=6IklCDHhgQorI2nvSY70LttY9OSzBrXc2GgedzCxs3A=;
b=VHYsw13703RGIy9HI7CM6tFRSBGL/+nE6Rr5uPBdUJf+ORRyFObJ8+f0FAqI2ALjJm
wQz6/WY8UxWA+RWJ8CJY7H65DXvXfhx3DgJYr1NB45EkVXIZvj/uCLhI617cuE6Xbl+U
vzoTBDcyq8t0ioAJRKkyMKrYS4kJjAcRimDQiZiZMGAS6FqbXbZnrHOOXXSw/vqjw+Jb
5CA0RNIGoWA+mJrUPaBTDHoWo7k53Kyg/T0haRnxjVWqSTYg4DiA6emNlRbueIsTBnRZ
XDP22InjXQtv+TtJanpzH3Q+VlI47P1sFt+TxHWeQ/0rDzUNz62FJweGbdfLCHsnnV4x
6x4g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1760262279; x=1760867079;
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=6IklCDHhgQorI2nvSY70LttY9OSzBrXc2GgedzCxs3A=;
b=xI9wrNrhrejFevkhv6wQQVAv4IDEDMtoSGJJRpZ1YPuwco2jxzW6yxHBKAo5cNrJo2
/6quH+L1oUOxEBczctLcKmC/cuduul+D2Ms6MPZ7Fp5cUbrMfWPTz96KjJqAXl7+VgEr
FS66ijyuqoZz2b+Gvw9idMWY0OQJXmbFOjSAWVHkG7zqhauU7NQ4joqossZcqyeVWfZ8
j4BaxYdBoKkaxikvjxf5dZK9TUlvLEc/1XC8nAIoqpNzI3GLFtx7+z1j+RGlChD63oRL
EZjDDzE8ou9RxVEkYwTP15MdUyW2kOblGI5Gcn874H/cHwd62DctOyVhalP64m+xWA2K
vXOQ==
X-Forwarded-Encrypted: i=1;
AJvYcCXWCf4tuDcd3NYl3DTApt/qkwJLhJZiBuDpcVrNbcriH0Lr/dxnBwJJNYZOgi7JKEa8ocSZPQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yz1NX0mlBHLZGIF2bh+XSGcSwSnkZxCULWlyhmZSrcLgfz+svL1
MDzWzhj9GUc/S82ystG3/s+pk0j+l/IGEkwJtPcjs+cKzv+dpbbP9dH9fl9IBw==
X-Gm-Gg: ASbGncsQJ4LBfLlSPaX780Xsh9TxTa0S/HS8VmyURUSD++v9ENKeaXAb3a2k0Ibaw4/
sFFzT50Rfal8Dmdw4kmcXZhuDgZvbEV9kNUXsfGUy8zq3I2F3LR0okk+9aOXAzbpmVeQUDb6wHn
3LKtmX2IsIBe0H3Wfn9ioke/f/7EflkW/qg3IjLFLi4jfoyo7j2T3ZyvRpWSIFOY8gmtOyZgSyO
QyZLwUNlqLgew8iDSPYvCQRhGhAMKNbMG4aCGfjxnDa8CpEWpE1hRy4jy2XlFESqG4cfQdHXS92
/lEfyMudcg2ktano+1cPu25ZtganYghMMa0wDSblR31B6x8KOxguMvnW5SGVSGq1ytSBLqDN2bi
NX+iPYY6ntSGABBENFlqf75xRr4yE/1GB28yh5/knvNnejUnyW4EWnoQfsCaaTOK1vXcJwbB5Ji
NvPW3JXbah6ON0ckdO11Via8ZRRhiJzxVhXWHgwp1+SC6K9u2gK7s2leZeOu2Q
X-Google-Smtp-Source: AGHT+IExiQXx7M/PppWVPWQ/rWErF33NbABQY8Vi7jxEvDCSX/uXH24la6/2C1cJdPAX2kjJN7ofkA==
X-Received: by 2002:a05:600c:1986:b0:45f:27fb:8016 with SMTP id
5b1f17b1804b1-46fa9a89388mr117337435e9.1.1760262279222;
Sun, 12 Oct 2025 02:44:39 -0700 (PDT)
Received: from pro4 (p200300e0b730ea00f4ec76711c957195.dip0.t-ipconnect.de.
[2003:e0:b730:ea00:f4ec:7671:1c95:7195])
by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-426d0d9050bsm10947013f8f.13.2025.10.12.02.44.37
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sun, 12 Oct 2025 02:44:38 -0700 (PDT)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Helmut Eller <eller.helmut@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <87347rxo57.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
<87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN>
<87frbszhwn.fsf@HIDDEN> <87ikgoczj2.fsf@HIDDEN>
<m2frbs5www.fsf@HIDDEN> <m2bjmg5omn.fsf@HIDDEN>
<875xcnzzft.fsf@HIDDEN> <871pnbdhw8.fsf@HIDDEN>
<877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN>
<87347rxo57.fsf@HIDDEN>
Date: Sun, 12 Oct 2025 11:44:37 +0200
Message-ID: <m21pn8jvy2.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: 79584
Cc: 79584 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>,
oliver.reiter@HIDDEN, 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 (-)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Helmut Eller <eller.helmut@HIDDEN> writes:
> On Thu, Oct 09 2025, Gerd M=C3=B6llmann wrote:
>
>>> It would mean that all objects referenced by the AMS pool are pinned.
>>> Which could be useful.
>>
>> Who makes sure that objects in AMS get scanned and pin referenced
>> objects? How does MPS detect when references in AMS objects change when
>> there are no barriers? Ans so on.
>
> It looks like it's not implemented. I added the MPS_KEY_RANK argument,
> but then (require 'vterm) triggers this assertion:
>
> #5 traceFindGrey (segReturn=3D<synthetic pointer>,=20
> rankReturn=3D<synthetic pointer>, arena=3D0x7ffff7fbe000, ti=3D0)
> at ../mps/code/trace.c:1103
> 1103 AVER(RingIsSingle(ArenaGreyRing(arena, RankAMBIG)));
>
> Disappointing.
Please find attached the "final" version of what I have in my Emacs,
ported to feature/igc. No further gymnastics needed for modules. I'd
like to apply that, okay with you?
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=0001-Replace-AMS-pool-for-immovable-objects-bug-79584.patch
From 530caa9bef3f41c4484646427b0b5df1ffbe2e32 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Date: Thu, 9 Oct 2025 12:32:51 +0200
Subject: [PATCH] Replace AMS pool for immovable objects (bug#79584)
This replaces the AMS pool with an AMC pool + pinning.
* src/igc.c (struct igc_pins): New.
(struct igc): Add member pins.
(pin, unpin, amke_pins, count_pins, enlarge_pins): New
functions.
(make_fake_entry_pins): New function.
(Figc_info): Use make_fake_entry_pins.
(igc_thread_remove): Unpin thread_state.
(igc_alloc_global_ref): Pin allocated global ref.
(igc_free_global_ref): New function.
(make_pool_ams): Remove.
(make_igc): Make immovable pool and AMC pool.
* src/igc.h (igc_free_global_ref): Declare.
* src/emacs-module.c (module_free_global_ref): Call
igc_free_global_ref.
* src/lisp.h (struct thread_state): Add member pin_index.
* src/thread.h (GCALIGNED_STRUCT): Add member pin_index.
* src/igc.c
---
src/emacs-module.c | 7 ++-
src/igc.c | 114 +++++++++++++++++++++++++++++++++++++++++----
src/igc.h | 3 ++
src/lisp.h | 4 ++
src/thread.h | 1 +
5 files changed, 120 insertions(+), 9 deletions(-)
diff --git a/src/emacs-module.c b/src/emacs-module.c
index f3a92500f62..c6a528baf6a 100644
--- a/src/emacs-module.c
+++ b/src/emacs-module.c
@@ -471,7 +471,12 @@ module_free_global_ref (emacs_env *env, emacs_value global_value)
struct module_global_reference *ref = XMODULE_GLOBAL_REFERENCE (value);
eassert (0 < ref->refcount);
if (--ref->refcount == 0)
- hash_remove_from_table (h, obj);
+ {
+ hash_remove_from_table (h, obj);
+#ifdef HAVE_MPS
+ igc_free_global_ref (ref);
+#endif
+ }
}
MODULE_INTERNAL_CLEANUP ();
diff --git a/src/igc.c b/src/igc.c
index 9947abde71b..bf9dc7699fa 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -34,7 +34,6 @@
#include "../mps/code/mps.h"
#include "../mps/code/mpsavm.h"
#include "../mps/code/mpscamc.h"
-#include "../mps/code/mpscams.h"
#include "../mps/code/mpscawl.h"
#include "../mps/code/mpslib.h"
#ifdef __clang__
@@ -929,6 +928,21 @@ IGC_DEFINE_LIST (igc_root);
typedef struct igc_thread igc_thread;
IGC_DEFINE_LIST (igc_thread);
+/* The following struct is used to register/deregister objects that
+ should not move in memory. Objects are made immovable by
+ creating/removing ambiguous references to them. This is part of the
+ global struct igc. */
+
+struct igc_pins
+{
+ ptrdiff_t capacity;
+ ptrdiff_t free;
+ union {
+ void *obj;
+ ptrdiff_t next_free;
+ } *entries;
+};
+
/* The registry for an MPS arena. There is only one arena used. */
struct igc
@@ -959,10 +973,81 @@ IGC_DEFINE_LIST (igc_thread);
/* Registered threads. */
struct igc_thread_list *threads;
+
+ /* Ambiguous references to objects to make them immovable. */
+ struct igc_pins *pins;
};
static bool process_one_message (struct igc *gc);
+/* Allocate new initialized igc_pins structure. */
+
+static struct igc_pins *
+make_pins (void)
+{
+ struct igc_pins *p = xzalloc (sizeof *p);
+ p->free = -1;
+ return p;
+}
+
+/* Make sure that at least 1 free pin entry exists in P. */
+
+static void
+ensure_free_pin (struct igc_pins *p)
+{
+ if (p->free < 0)
+ {
+ const ptrdiff_t used = p->capacity;
+ p->entries = igc_xpalloc_ambig (p->entries, &p->capacity, 1, -1,
+ sizeof *p->entries);
+ for (ptrdiff_t i = used; i < p->capacity; ++i)
+ {
+ p->entries[i].next_free = p->free;
+ p->free = i;
+ }
+ }
+}
+
+/* Pin OBJ. This add an ambiguous reference to OBJ to the pin registry
+ of GC, which makes OBJ immovable, and also means that OBJ will not
+ die before that reference is removed again by calling unpin. Value
+ is the index of the pin entry, which is needed to unpin. */
+
+static ptrdiff_t
+pin (struct igc *gc, void *obj)
+{
+ struct igc_pins *p = gc->pins;
+ ensure_free_pin (p);
+ const ptrdiff_t e = p->free;
+ p->free = p->entries[e].next_free;
+ p->entries[e].obj = obj;
+ return e;
+}
+
+/* Unpin OBJ in GC. I is the index of the pin returned when calling
+ pin. */
+
+static void
+unpin (struct igc *gc, void *obj, ptrdiff_t i)
+{
+ struct igc_pins *p = gc->pins;
+ eassert (p->entries[i].obj == obj);
+ p->entries[i].next_free = p->free;
+ p->free = i;
+}
+
+/* Return the number of pins recorded in GC. */
+
+static ptrdiff_t
+count_pins (struct igc *gc)
+{
+ struct igc_pins *p = gc->pins;
+ ptrdiff_t n = p->capacity;
+ for (ptrdiff_t i = p->free; i >= 0; i = p->entries[i].next_free)
+ --n;
+ return n;
+}
+
/* The global registry. */
static struct igc *global_igc;
@@ -3312,6 +3397,7 @@ igc_thread_remove (void **pinfo)
{
struct igc_thread_list *t = *pinfo;
*pinfo = NULL;
+ unpin (global_igc, t->d.ts, t->d.ts->pin_index);
destroy_root (&t->d.stack_root);
destroy_root (&t->d.specpdl_root);
destroy_root (&t->d.bc_root);
@@ -4320,8 +4406,15 @@ igc_alloc_global_ref (void)
struct Lisp_Vector *v
= alloc_immovable (header_size + nwords_mem * word_size, IGC_OBJ_VECTOR);
XSETPVECTYPESIZE (v, PVEC_MODULE_GLOBAL_REFERENCE, 0, nwords_mem);
+ ((struct module_global_reference *) v)->pin_index = pin (global_igc, v);
return v;
}
+
+void
+igc_free_global_ref (struct module_global_reference *r)
+{
+ unpin (global_igc, r, r->pin_index);
+}
#endif
Lisp_Object
@@ -4406,6 +4499,7 @@ igc_alloc_pseudovector (size_t nwords_mem, size_t nwords_lisp,
scanning the bytecode stack (scan_bc), and making thread_state
immovable simplifies the code. */
v = alloc_immovable (client_size, IGC_OBJ_VECTOR);
+ ((struct thread_state *) v)->pin_index = pin (global_igc, v);
}
else
v = alloc (client_size, IGC_OBJ_VECTOR);
@@ -4801,6 +4895,14 @@ make_fake_entry (const char *name, double (*f) (mps_arena_t),
Qnil);
}
+static Lisp_Object
+make_fake_entry_pins (const char *name)
+{
+ return list4 (build_string (name), Qnil,
+ make_uint (count_pins (global_igc)),
+ make_uint (global_igc->pins->capacity));
+}
+
DEFUN ("igc-info", Figc_info, Sigc_info, 0, 0, 0,
doc: /* Return information about incremental GC.
The return value is a list of elements describing the various
@@ -4848,6 +4950,7 @@ form (NAME NOBJECTS NBYTES LARGEST), where:
mps_arena_spare_committed, a),
make_fake_entry ("commit-limit", NULL, mps_arena_commit_limit, a),
make_fake_entry ("committed", NULL, mps_arena_committed, a),
+ make_fake_entry_pins ("pins (used, capacity)"),
};
for (size_t i = 0; i < ARRAYELTS (fake_entries); i++)
result = Fcons (fake_entries[i], result);
@@ -5081,12 +5184,6 @@ make_pool_amc (struct igc *gc, mps_fmt_t fmt)
return make_pool_with_class (gc, fmt, mps_class_amc (), NULL);
}
-static mps_pool_t
-make_pool_ams (struct igc *gc, mps_fmt_t fmt)
-{
- return make_pool_with_class (gc, fmt, mps_class_ams (), NULL);
-}
-
static mps_pool_t
make_pool_awl (struct igc *gc, mps_fmt_t fmt, mps_awl_find_dependent_t find_dependent)
{
@@ -5111,6 +5208,7 @@ make_pool_amcz (struct igc *gc, mps_fmt_t fmt)
make_igc (void)
{
struct igc *gc = xzalloc (sizeof *gc);
+ gc->pins = make_pins ();
make_arena (gc);
/* We cannot let the GC run until at least all staticpros have been
@@ -5127,7 +5225,7 @@ make_igc (void)
gc->weak_hash_fmt = make_dflt_fmt (gc);
gc->weak_hash_pool = make_pool_awl (gc, gc->weak_hash_fmt, weak_hash_find_dependent);
gc->immovable_fmt = make_dflt_fmt (gc);
- gc->immovable_pool = make_pool_ams (gc, gc->immovable_fmt);
+ gc->immovable_pool = make_pool_amc (gc, gc->immovable_fmt);
root_create_charset_table (gc);
root_create_buffer (gc, &buffer_defaults);
diff --git a/src/igc.h b/src/igc.h
index 13b5646f387..36d4d99b9b7 100644
--- a/src/igc.h
+++ b/src/igc.h
@@ -80,7 +80,10 @@ #define EMACS_IGC_H
void igc_remove_all_markers (struct buffer *b);
void igc_resurrect_markers (struct buffer *b);
Lisp_Object igc_alloc_symbol (void);
+#ifdef HAVE_MODULES
void *igc_alloc_global_ref (void);
+void igc_free_global_ref (struct module_global_reference *ref);
+#endif
struct Lisp_Buffer_Local_Value *igc_alloc_blv (void);
void *igc_alloc_handler (void);
diff --git a/src/lisp.h b/src/lisp.h
index 391c5bef6e9..9a51a75ffed 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -6356,6 +6356,10 @@ maybe_gc (void)
/* Pseudovector header, must come first. */
struct vectorlike_header header;
+# ifdef HAVE_MPS
+ ptrdiff_t pin_index;
+# endif
+
/* Holds the emacs_value for the object. The Lisp_Object stored
therein must be the same as the hash key. */
struct emacs_value_tag value;
diff --git a/src/thread.h b/src/thread.h
index f50a627cb33..895c4944f29 100644
--- a/src/thread.h
+++ b/src/thread.h
@@ -228,6 +228,7 @@ #define getcjmp (current_thread->m_getcjmp)
# ifdef HAVE_MPS
void *gc_info;
+ ptrdiff_t pin_index;
# endif
} GCALIGNED_STRUCT;
--
2.51.0
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 10 Oct 2025 06:32:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 10 02:32:50 2025
Received: from localhost ([127.0.0.1]:40840 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v76gL-0008Ey-Mc
for submit <at> debbugs.gnu.org; Fri, 10 Oct 2025 02:32:50 -0400
Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]:44443)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>)
id 1v76gH-0008E4-GM
for 79584 <at> debbugs.gnu.org; Fri, 10 Oct 2025 02:32:46 -0400
Received: by mail-ed1-x52f.google.com with SMTP id
4fb4d7f45d1cf-637e74e9104so2291284a12.1
for <79584 <at> debbugs.gnu.org>; Thu, 09 Oct 2025 23:32:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1760077959; x=1760682759; 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=9GAKoun0jwh4dxM89FBkmp/89c4afAw1zkxrEwwj8/M=;
b=a3O0gyX98rM5qqdF91bZQWdlQ8XcDtASasfxcc0d74iwt/LVjpVdna+Gfgexd7T5lx
/hz7yP41/EXGwfOtdU1m79kfXjpjrDXtLetgDFPnM2HMxjSxAsha48OOXwPu2NpX9C3i
bwXXJx3euR+Ua3lrCflMeOtx+MtEU29VVsIAJJr3ocTKfNnMppvezb35s1TPoGT6wVwt
wOHdk7J8KC98TJywH7MR112+qkbaH/jVHmAyyFu3tqKphZ39dIAFRJWCvON+UNxu/BqP
NxUetJH6TPUZksC1sxnqjXQA2XR5EVQoZLa3TWDLI9THu+Erp5cVVV3Ecp8Brj+n/KgS
vlAA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1760077959; x=1760682759;
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=9GAKoun0jwh4dxM89FBkmp/89c4afAw1zkxrEwwj8/M=;
b=auItsHDkz3DB09a/i9iYzFFmwQd1rONT3dPrOC2fsnAYJs4tTj6br2x+4o6PV2fTYp
KeFwHmCeCXm+UiaIDVt+EC4lIP7OXI+BeYjQk3hawfcMYFPTQGGlE0ONz//PGPGOgSFJ
dr4h5unnaa/ca+ZMmaLsYiqZYB/YzIqE07RqolDxwrB9eiRqO8pm4xbC9MY9vl2X2Eke
Rh7pUXzHDvlo1uCwc+hGgf2poQZL+g9iOm91leYj4CWhUqCtlRKVM2LhIGRakoVN69Pp
eN7jGfclMXgIiJUv9zKH1sBygjVAhYOyN59DrAxrAonJNWRCdUftP4lS4A2Jfq/YzC7y
00DQ==
X-Forwarded-Encrypted: i=1;
AJvYcCXSbTYjxCGGFfR1yxVG0l91UvhnqXJyD1ff00U8AT74JydFsWlPzY1ERnGn8+ydYgYUG0DCRQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzYHGCB+RtX6zvYrVwnvjJkXgcF9lzJZe8pkiOjnTQmFxkGauNh
xHXQBIkhndBmRrtByz80sR8bQ7ciqLfWiKl99RUf3x/JukvFUC96gT/hmw3yZQ==
X-Gm-Gg: ASbGncvT1qcs6rS1QFjeFTlDNY9b18kPBr/y7Urar4Hei48x8WY+/yzvhSTukN/eoTn
f8Fmo6pU/RIlrCgwWa44jo6H4BYEoD9PnlmGJ/Ljb3uY0ZlBR81AN9pGKkdzZrV5PPIoG5bskgJ
JGzsgCfPp7beAX4CpmUj8XZ0KV8TyPoqEQepOSKaPYX1gqKq8D0GwQCv9TKtVxTkIo/pt+PzDPy
y/C6P3pxq9OvJeFf2O2lNdCfV2ZgNHrRVCeSj7hZL5Z8N54BUpJ7wZ8x2vhuASQCUk4RiZU4ncr
JpiYAmTvX67a2vibngy1cquyO5gzsyt1SRrcalxITClVHH/wqpbVBXMHoev90MxjfkBvRRLZ/EV
l8k/3jHayO1gT7d9kFjt0voIMmdbbssaK+xSzRvI=
X-Google-Smtp-Source: AGHT+IGkQULwGmIlsUTYlOLDa1yB9DZsPLuZYIhVplqk2XbdObFQIszo0TrZLr2LlsNQJy2j9VWOXA==
X-Received: by 2002:a17:907:948f:b0:b40:e7ee:b5ec with SMTP id
a640c23a62f3a-b50ac6c92d4mr1117376566b.59.1760077958548;
Thu, 09 Oct 2025 23:32:38 -0700 (PDT)
Received: from caladan ([31.177.112.212]) by smtp.gmail.com with ESMTPSA id
a640c23a62f3a-b55d69dbd99sm152527966b.40.2025.10.09.23.32.37
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 09 Oct 2025 23:32:38 -0700 (PDT)
From: Helmut Eller <eller.helmut@HIDDEN>
To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <m2v7knnal7.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
<87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN>
<87frbszhwn.fsf@HIDDEN> <87ikgoczj2.fsf@HIDDEN>
<m2frbs5www.fsf@HIDDEN> <m2bjmg5omn.fsf@HIDDEN>
<875xcnzzft.fsf@HIDDEN> <871pnbdhw8.fsf@HIDDEN>
<877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN>
Date: Fri, 10 Oct 2025 08:32:36 +0200
Message-ID: <87347rxo57.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: 79584
Cc: 79584 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>,
oliver.reiter@HIDDEN, 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 (-)
On Thu, Oct 09 2025, Gerd M=C3=B6llmann wrote:
>> It would mean that all objects referenced by the AMS pool are pinned.
>> Which could be useful.
>
> Who makes sure that objects in AMS get scanned and pin referenced
> objects? How does MPS detect when references in AMS objects change when
> there are no barriers? Ans so on.
It looks like it's not implemented. I added the MPS_KEY_RANK argument,
but then (require 'vterm) triggers this assertion:
#5 traceFindGrey (segReturn=3D<synthetic pointer>,=20
rankReturn=3D<synthetic pointer>, arena=3D0x7ffff7fbe000, ti=3D0)
at ../mps/code/trace.c:1103
1103 AVER(RingIsSingle(ArenaGreyRing(arena, RankAMBIG)));
Disappointing.
Helmut
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 10 Oct 2025 05:48:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 10 01:48:52 2025 Received: from localhost ([127.0.0.1]:40755 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v75zn-0005QK-LJ for submit <at> debbugs.gnu.org; Fri, 10 Oct 2025 01:48:51 -0400 Received: from mail-wm1-x331.google.com ([2a00:1450:4864:20::331]:59746) 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 1v75zk-0005Q0-9d for 79584 <at> debbugs.gnu.org; Fri, 10 Oct 2025 01:48:48 -0400 Received: by mail-wm1-x331.google.com with SMTP id 5b1f17b1804b1-46e6c8bc46eso9597475e9.3 for <79584 <at> debbugs.gnu.org>; Thu, 09 Oct 2025 22:48:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760075321; x=1760680121; 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=8Ud4A5g2UcZEqh7z5eBSkxhk+ExnBbpTgJhf1+5gZ8M=; b=fGg0pykV5MthdqelOEFlIRkj7CjdOViF86UQuf140rtIioqyfBHwlnU4VlfVWX92RB HwApS2dO7KqwWfIzXqWvxkyRBIHCL/KYBVxf6o/iUxLPbCwm8U2YlmjR+62QFt95Eycf HW+Hi2eQqdykarFSQBGUEvL0G2YsByerivnIfaU+oNHnfRSnR+a1eKl2I3Ib6KaX22xN joC/YR2Zv0b+j4J07BJIGNKlZzS4Qgeg3fdIOW0hk1yBX7BPIkPZm4UkpjZs0+HCl2JQ f8MFTNvJkMJOBRlQyS+f+nrsJW8fIb6V32ckoJ7V6BzsycWw8fgQke1QDAmaWmAURrqQ /63Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760075321; x=1760680121; 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=8Ud4A5g2UcZEqh7z5eBSkxhk+ExnBbpTgJhf1+5gZ8M=; b=JNA1zedceLwxRcVzN7fEMuBaJaKdWTYaEmgerUaetz4KfST8VwsORf7AOElN3dLqfz OPvF7xXTBDWM5D6ZoRa2IPFBEFJLXhPOJv6FA91ngItPY3wvw0zHJt1/SSGgz2TPd8Wl iDmhtJjkjxRPFcjqqlJBef7qm05qEtrUIwQQtTRROrr7f9ZXmtRljujIJLOCaiTyiry6 NyDrJFPYMW7n6eOEJO1CCu6Gnokzw2z6OyFwQwB9g6KxRa3PXO+ACFRMsnRd04X50G7a LGLPfbHN8aLPFWkC3bAvUPhBKdak3R9uw/is4u+7b04L4PVVmk8mmR/VeEImDdVj3yJY ac1g== X-Forwarded-Encrypted: i=1; AJvYcCV0ajORLstvlcg4EJlD5CC2RMXsb+zVGGOOzj1zLI63gd4CdbAKGzVEszYuY3KZ2nnzTYOWVg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzjCFL7eWIcvVcwBq4tF4NgGPHUKM7LcqvduJCV7yRNh1qwPQKO 0GWBBgD++UzRnR2iLUnt9iaIaEFm1zWzUUkkXGYdPTzWVIjToW7xaMsd+ZjAzA== X-Gm-Gg: ASbGncutfT3VZm3Hf2t198jjH7OnEVk0pNN3F9oXo7ee1tMhcMhVx3RDm2cSUMW0BeZ ol5KYm1AUT3UttxppHMGhBhptM0L8YgPYVMtQtG2s+1JIn85XukjUXrZLsAU83v6FwhtE5OIOOH nCnFqMGjAN9ADtPJ1f9frwR/qqdBcwFp9kqQfdd9hTcp9lNFl9VXLzr3EF9VTAQbJqNrLBRKsgc pMk1QW7GXFqp7S77ElTSurrFxU9c1Kmv6afMpWOICvxyYEP/R3pRBQcCj2j/asWchIFAp1A8Dz+ OjpNPpCzCA7MyUN/kI4WZGZuvAMLA2pbOIgZAL/+CHQblS5SvaIAqXkPOOTp4jVCPBpvncdKdub 2CDaJ9gcdNZnAbfsgcJqGZUKDc8EjQWxSFpwOkG3mM1Y+dx7N/9JN7GxG2Cdm6KsOH+hMNqOYXk wJxvkZ2u4X8KNGIj1pNb7uX1zNHKCNUrveYWbwS5ncdpDfz5QP X-Google-Smtp-Source: AGHT+IEeDTeAKR6IrGLsIqFm3Sy0pmqh+3wRBzuavWRgim0bgIrj2epXVqt9/8BTejjQh1oc+zZOnQ== X-Received: by 2002:a05:600c:1986:b0:46e:4246:c90d with SMTP id 5b1f17b1804b1-46fa9aa4711mr70753975e9.11.1760075321175; Thu, 09 Oct 2025 22:48:41 -0700 (PDT) Received: from pro4 (p200300e0b7176600b093369d223803bd.dip0.t-ipconnect.de. [2003:e0:b717:6600:b093:369d:2238:3bd]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-426ce5cfe4esm2305161f8f.26.2025.10.09.22.48.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Oct 2025 22:48:40 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Helmut Eller <eller.helmut@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <m2v7knnal7.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m21pndpqtv.fsf@HIDDEN> <87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN> <87frbszhwn.fsf@HIDDEN> <87ikgoczj2.fsf@HIDDEN> <m2frbs5www.fsf@HIDDEN> <m2bjmg5omn.fsf@HIDDEN> <875xcnzzft.fsf@HIDDEN> <871pnbdhw8.fsf@HIDDEN> <877bx3yjxs.fsf@HIDDEN> <m2v7knnal7.fsf@HIDDEN> Date: Fri, 10 Oct 2025 07:48:39 +0200 Message-ID: <m2zf9zgvd4.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: 79584 Cc: 79584 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>, oliver.reiter@HIDDEN, 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 (-) Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN> writes: Before I forget it: Since yesterday I'm running with AMS removed, and it works fine. The root this introduces is 64 pointers large ATM in this Emacs, which is nothing compared to other things, let me just mention elns. Anyway, what I wanted to say is please trigger me if you decide want that. I've added some comments, and something to igc-info. PS: =F0=9F=91=8D for AWL0 :-)
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 9 Oct 2025 19:23:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 09 15:23:52 2025
Received: from localhost ([127.0.0.1]:39535 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6wEx-0000kA-GE
for submit <at> debbugs.gnu.org; Thu, 09 Oct 2025 15:23:52 -0400
Received: from [2a00:1450:4864:20::331] (port=43365
helo=mail-wm1-x331.google.com)
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 1v6wEj-0000jH-WE
for 79584 <at> debbugs.gnu.org; Thu, 09 Oct 2025 15:23:38 -0400
Received: by mail-wm1-x331.google.com with SMTP id
5b1f17b1804b1-46e326e4e99so12216585e9.1
for <79584 <at> debbugs.gnu.org>; Thu, 09 Oct 2025 12:23:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1760037798; x=1760642598; 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=rDcM52gx8oind953Ng5/2XY/gHTyOfZeXOJ3XaUw/WM=;
b=X33Cq1/dNWUSaxgoNDtYOU518JLQG8HcDwmFapD6cIVibvbIzp6RkAhdSPA0nL/ASU
dxCZaQzwnjdwcxPJCMEasMi+ktde2tS7M0e8UTz8+aMuSy/ibw2ONMzqQO6ZorUUBoia
W8LxCyJyLzC1bvKfM5SM+Fl2KlbFLvvSmAJxIr75bemI01Lpc56MA57IrZwHJjlMd4DA
HVHTEpCx1u4hnRVW5em9Du2TSJCQTZ4DM6lVXVEb17dhCcMsTuHChUlCsow8vSNeaxRe
TnS3TbB9NJL5GO/wWcesv1Cf3TmBOKVeIPSKRG4C3uFu4V1O3tRv/O98M6vGeui/Nd1C
6Skw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1760037798; x=1760642598;
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=rDcM52gx8oind953Ng5/2XY/gHTyOfZeXOJ3XaUw/WM=;
b=OfRobFSK26sumhHgYCbVQE7T0WJzqsBUPlcUqNqns6l/zz61SIMK8eehlVh4Cp9lod
HCtIN3P/fSgGLUhP8MOQ5iF8z7F/AV2PZb6RQSYGsj5b35wCefuyih6QsdRl/xBfsH1i
sZUyQmddD56thlFaFvzrVT8DGtjwAgFInZ0BtMIgjxgieerRKLlCiY92SY/7WrYUUyxV
I3AE+J9vgUmHqZYz85iZL+SxM4u8yQzr3ytIIniju9YUGdk3z69UEZZ2iR5YZdlvWpIq
Dg9EzM6x+iQRlooXWB6+8kUCI3gKo2gIBCDywAMQHhY/4ib4v7ETljTvdzjWEXZjPx+M
xd7w==
X-Forwarded-Encrypted: i=1;
AJvYcCXHhDI26VFNB+iToHHvo1TMSLLpq27zExFP2fmAyzuZrKDTIkPq70ng/MsmhCdHRXKpMyMB1A==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yw5q6tSPDahuGuFYyENgKay3oBqBMTZUx9M44bnI+Na4YUg4mDB
xKLjDcZCaun28bxArdspOivEz4vfnlR8ATTGQWGipIn3CZj7sDc7Uj10y5553g==
X-Gm-Gg: ASbGnctHZi9eM1nVxj2v/rO22V1+lOCev8Rg+c0hBsg3n9HZJO0FeL3JCSDDMIneL+X
cMp0nc7EVKNUbkqL8e4rujmqAgDSEkMua0sIO1teOYPLOyYb4bM1s2sc0ACx0FR7WrLFwbF9yaE
bEkmYtmZwwn8xg/c5PbZGzZC1i1/ZzsI72FJE/dHxYj84uGBuo+i47WYpiJqumb6resOlY4qYLA
PGfNB/AYVLSbwiDLKzjz2ODE72P9zBeFFForHiUCbHvwJIOs0VLw6nlCKLtJEyW/vCWAXazGKkQ
Basi7uYvoi0jrjRQE+qDtEgcMPb8gV3tw604jnkXKFwdCl8D9waf+f2lon57ll57XrQKDsD2BSF
C6v7kSkKpkZ+aieJoNSvIGByMsPwIWMQsnn35DwCNFKA19Ad6wrwx2uIpGTKJG9PAvXUa1GdS4F
Fbze57rDVCS6mRj2EPL8N6AmfCF8+IGH3QThofKB6pIvj2+p/RCHpve8o8xLefKsJhxg==
X-Google-Smtp-Source: AGHT+IE3GSOXRwiR0h9uSbzhIrQJum3OFXe9igtWHnV46hsHG902Ph1pLWJ0iGk/mFPBXPhD54rUoA==
X-Received: by 2002:a05:600c:450e:b0:46e:1a60:c995 with SMTP id
5b1f17b1804b1-46fa9e8dcc7mr67820455e9.2.1760037798140;
Thu, 09 Oct 2025 12:23:18 -0700 (PDT)
Received: from pro4 (p200300e0b70e3c003c678e8076e0cee7.dip0.t-ipconnect.de.
[2003:e0:b70e:3c00:3c67:8e80:76e0:cee7])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-46fab3d438fsm44367995e9.2.2025.10.09.12.23.16
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 09 Oct 2025 12:23:17 -0700 (PDT)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Helmut Eller <eller.helmut@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <877bx3yjxs.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
<87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN>
<87frbszhwn.fsf@HIDDEN> <87ikgoczj2.fsf@HIDDEN>
<m2frbs5www.fsf@HIDDEN> <m2bjmg5omn.fsf@HIDDEN>
<875xcnzzft.fsf@HIDDEN> <871pnbdhw8.fsf@HIDDEN>
<877bx3yjxs.fsf@HIDDEN>
Date: Thu, 09 Oct 2025 21:23:16 +0200
Message-ID: <m2v7knnal7.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.3 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
has NOT identified this incoming email as spam. The original
message has been attached to this so you can view it or label
similar future email. If you have any questions, see
the administrator of that system for details.
Content preview: Helmut Eller writes: > On Thu, Oct 09 2025, Pip Cet wrote:
> >> "Helmut Eller" writes: >> >>> On Thu, Oct 09 2025, Gerd Möllmann wrote:
>>> >>>> I meanwhile distrust AMS so deeply that I can't help it, and there
is in [...]
Content analysis details: (1.3 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/,
no trust
[2a00:1450:4864:20:0:0:0:331 listed in]
[list.dnswl.org]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail
provider (gerd.moellmann[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.3 RDNS_NONE Delivered to internal network by a host with no rDNS
X-Debbugs-Envelope-To: 79584
Cc: 79584 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>,
oliver.reiter@HIDDEN, 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.3 (/)
Helmut Eller <eller.helmut@HIDDEN> writes:
> On Thu, Oct 09 2025, Pip Cet wrote:
>
>> "Helmut Eller" <eller.helmut@HIDDEN> writes:
>>
>>> On Thu, Oct 09 2025, Gerd M=C3=B6llmann wrote:
>>>
>>>> I meanwhile distrust AMS so deeply that I can't help it, and there is =
in
>>>> addition struct thread_state which is also allocated in AMS and so on.
>>>> I think I'll try replacing AMS in my Emacs.
>>>
>>> Maybe we're using the AMS pool incorrectly: when creating the
>>> immovable_ap, shouldn't there be an MPS_KEY_RANK =3D mps_rank_ambig()
>>> argument?
>>
>> IIUC, that would mean references *in* the AMS pool can be ambiguous. We
>> don't want that. We want ambiguous references *to* objects in the AMS
>> pool, which is MPS_KEY_AMS_SUPPORT_AMBIGUOUS, and we want them to
>> preserve objects even if they're interior pointers, which there is no
>> option for (for AMC, it's MPS_KEY_INTERIOR).
>
> It would mean that all objects referenced by the AMS pool are pinned.
> Which could be useful.
Who makes sure that objects in AMS get scanned and pin referenced
objects? How does MPS detect when references in AMS objects change when
there are no barriers? Ans so on.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 9 Oct 2025 19:06:06 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 09 15:06:05 2025 Received: from localhost ([127.0.0.1]:39498 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6vxl-0008SV-IC for submit <at> debbugs.gnu.org; Thu, 09 Oct 2025 15:06:05 -0400 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:61839) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>) id 1v6vxg-0008Rr-Cy for 79584 <at> debbugs.gnu.org; Thu, 09 Oct 2025 15:06:02 -0400 Received: by mail-ed1-x529.google.com with SMTP id 4fb4d7f45d1cf-63994113841so2128019a12.3 for <79584 <at> debbugs.gnu.org>; Thu, 09 Oct 2025 12:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760036753; x=1760641553; 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=s3eI5GmVRpNPPeoboJPHJyu1qoY+3u7h5O3iW2oalj8=; b=Xe7EVW22nZwB0DkgJolqyR5p6KKWz3dWweZqHu5dEiEPFdO/xzKrDAVmRzniAbRNYi nHw8YQIqGrDmCi2ZWVp1qXV8xEr59uX0scQdqrwaTRAHiYGY+LWdD7nCo9mI4JDFJ0J3 K/1p7rr4yCh2udDhFtoM2ERD5yvgsAoOH/tnnLjFGj/d8crjj1ETAcfjl2AhREjMMV97 kv8mYBAWZn6BkItPsYgZC3pmRRws24wneJYL1QDWOFwFcLkaUQsouDdlA2PJc1NaiNDB oi/veb4VK+NS8VgVWOnKfHhYkgVgqajaYRnDtiHKofEUQNHLLGxk5TZgXKMYQer6dKuh pl1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760036753; x=1760641553; 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=s3eI5GmVRpNPPeoboJPHJyu1qoY+3u7h5O3iW2oalj8=; b=IGZt76XUvcuqFh+2UHQ/TLBXOQvwc4YsvvvKcIhLwCRJvXjFXnEwLPL7iEWfootNn/ qpRswXF6Mea6u3WqipyoEiV0kCkUxDr2ziKWdqY/QPGJfp3Oe5wHsOzIYOW9vg/C4MJ0 Tce9HOZjggp8OAozt1hOxohuJRKI/0YIKEVH2m8F5FqeyhskNXtNNDRFfBcUwpsJVqwz 3UrjpAPc37YquX7ryTgBJYvBEGZac7ubBFPwnLuZAWogVye9vTiKvvabKY7Xq/KGiPnp kH/L3qgIYGkpEzUqVXRp6Qn2I1ebatZZjE/4p5qJDG08hOVjZ5+S1iNJeyJxCCZacHT3 /GRQ== X-Forwarded-Encrypted: i=1; AJvYcCWeyVmLBzFHnyeodccT6ty9wGFIISJA9obY3E0H58mPnFu7MTWcMAvXEY6JDxBCPM/Qs0UOSg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzVmacB3lb46yGCfqzdFZtwM6MpfP06E7xORXuGyoEfd+gTJtsj uZ4+QoldvlHFiPPhcfv6q68zJgWnEF6RNQUeN8ByPmiEE6t6eqbG9r8avI85mA== X-Gm-Gg: ASbGncvbg6xY7b5zEaB80JHUY3tPS7u71+P6p55hzeJHdELYL0aACwLkiVA/dn88wKT Uuc9Y0mT0k3zsGLTmW8Wyt7TAcuCFDrURhlrUid+4hdtixZYG1qvxZEB/NupugX9lnGJ/GV7ytm UcYaqyw5wMviGFPU0G1SRQ1j6mBrucGyKqGRzNtTXZ6yqq+UD10SgEOr4bLmXM0KVI1jSL6s0fN TWvIo4BK8SHRrEyyK/Sja5S7QgIk3JeRBMEQ3k56KuQ566dYHQTBP9RDI5CwKgzUg/d+PxzBIfY oc8oegTEuH/dyHXSA0sZKA6U83JYZlMA3k7eEuu6gRXqvVBL2jQrpe03dDp5+Zygn6Aa1UKqdp7 BR8c3XOogPnRZFtba9Z2brC5ibDXHKPrQhC4vzre2qCwq X-Google-Smtp-Source: AGHT+IFCw23loD20RSR6b+0gYF1VpzrosrfPGFOvAh0ddxoQaH6rjB6pv6psdE/glEKqaN2e6W9azQ== X-Received: by 2002:a17:906:ef02:b0:b3f:f66b:268a with SMTP id a640c23a62f3a-b50aa08ef47mr1017141066b.19.1760036752559; Thu, 09 Oct 2025 12:05:52 -0700 (PDT) Received: from caladan ([31.177.112.212]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b55d8c12c48sm36866266b.50.2025.10.09.12.05.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Oct 2025 12:05:52 -0700 (PDT) From: Helmut Eller <eller.helmut@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <871pnbdhw8.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m21pndpqtv.fsf@HIDDEN> <87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN> <87frbszhwn.fsf@HIDDEN> <87ikgoczj2.fsf@HIDDEN> <m2frbs5www.fsf@HIDDEN> <m2bjmg5omn.fsf@HIDDEN> <875xcnzzft.fsf@HIDDEN> <871pnbdhw8.fsf@HIDDEN> Date: Thu, 09 Oct 2025 21:05:51 +0200 Message-ID: <877bx3yjxs.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: 79584 Cc: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, oliver.reiter@HIDDEN, 79584 <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 Thu, Oct 09 2025, Pip Cet wrote: > "Helmut Eller" <eller.helmut@HIDDEN> writes: > >> On Thu, Oct 09 2025, Gerd M=C3=B6llmann wrote: >> >>> I meanwhile distrust AMS so deeply that I can't help it, and there is in >>> addition struct thread_state which is also allocated in AMS and so on. >>> I think I'll try replacing AMS in my Emacs. >> >> Maybe we're using the AMS pool incorrectly: when creating the >> immovable_ap, shouldn't there be an MPS_KEY_RANK =3D mps_rank_ambig() >> argument? > > IIUC, that would mean references *in* the AMS pool can be ambiguous. We > don't want that. We want ambiguous references *to* objects in the AMS > pool, which is MPS_KEY_AMS_SUPPORT_AMBIGUOUS, and we want them to > preserve objects even if they're interior pointers, which there is no > option for (for AMC, it's MPS_KEY_INTERIOR). It would mean that all objects referenced by the AMS pool are pinned. Which could be useful. Helmut
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 9 Oct 2025 18:57:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 09 14:57:37 2025 Received: from localhost ([127.0.0.1]:39478 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6vpY-00083B-ST for submit <at> debbugs.gnu.org; Thu, 09 Oct 2025 14:57:37 -0400 Received: from mail-24416.protonmail.ch ([109.224.244.16]:46945) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1v6vpW-00082x-CO for 79584 <at> debbugs.gnu.org; Thu, 09 Oct 2025 14:57:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1760036247; x=1760295447; bh=Fh5RL59NoM67KoSLb8B+q2FS0SIFdvCLFoHDAEq6Jhs=; 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; b=lZ/+aOAPxmdNxfnMwEwaR5UcpEVCsnO67XLPvRmU5Nsm2l09sBNZ+aYSUUOS6ENNY jJWGTLSTSswSHmbwW15K3O2KgxsM0HJwr4Bu0xHIOEYRTiCaUyqMWlCpTqvZ4UUgxK Ie/pM8HSIrLDAVeZlVLgJ/UoF1v7XudzPpduyl/5Ggk7GoCblT9VlGvgpEoWaGO293 rcShtulQ9TtKoPEkexboZxGsXDJ77PSKIRsFkg78rSahgkrZFTTwQWDLaLHz6CZAPo Wap1/aZmYE94p1YQ71UHPyFY2y8h2XU+Vz+ZWTOhJ1Q0Sb9TKai5Ozv41l04FPtrst BKxlKHokwp37Q== Date: Thu, 09 Oct 2025 18:57:23 +0000 To: Helmut Eller <eller.helmut@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm Message-ID: <871pnbdhw8.fsf@HIDDEN> In-Reply-To: <875xcnzzft.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m21pndpqtv.fsf@HIDDEN> <87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN> <87frbszhwn.fsf@HIDDEN> <87ikgoczj2.fsf@HIDDEN> <m2frbs5www.fsf@HIDDEN> <m2bjmg5omn.fsf@HIDDEN> <875xcnzzft.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 2bf8b6957d8430c239a68ba8f60f23182638c7db 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: 79584 Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, oliver.reiter@HIDDEN, 79584 <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 (-) "Helmut Eller" <eller.helmut@HIDDEN> writes: > On Thu, Oct 09 2025, Gerd M=C3=B6llmann wrote: > >> I meanwhile distrust AMS so deeply that I can't help it, and there is in >> addition struct thread_state which is also allocated in AMS and so on. >> I think I'll try replacing AMS in my Emacs. > > Maybe we're using the AMS pool incorrectly: when creating the > immovable_ap, shouldn't there be an MPS_KEY_RANK =3D mps_rank_ambig() > argument? IIUC, that would mean references *in* the AMS pool can be ambiguous. We don't want that. We want ambiguous references *to* objects in the AMS pool, which is MPS_KEY_AMS_SUPPORT_AMBIGUOUS, and we want them to preserve objects even if they're interior pointers, which there is no option for (for AMC, it's MPS_KEY_INTERIOR). Pip
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 9 Oct 2025 18:45:54 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 09 14:45:54 2025 Received: from localhost ([127.0.0.1]:39459 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6veE-0007bQ-7W for submit <at> debbugs.gnu.org; Thu, 09 Oct 2025 14:45:54 -0400 Received: from mail-ej1-x629.google.com ([2a00:1450:4864:20::629]:57701) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>) id 1v6veA-0007bA-MQ for 79584 <at> debbugs.gnu.org; Thu, 09 Oct 2025 14:45:51 -0400 Received: by mail-ej1-x629.google.com with SMTP id a640c23a62f3a-b4c89df6145so191912866b.3 for <79584 <at> debbugs.gnu.org>; Thu, 09 Oct 2025 11:45:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1760035544; x=1760640344; darn=debbugs.gnu.org; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=0jJ96xGfYH9YmCqFaGgLXahbvelJ79KXl8RtWeyyy58=; b=cNOaoIJmlntcEM+uCIYaD+7tZSeraXJDGkbNCIw/x2aM3S4cYLnwPDr7Dtsnuwz3lL hCfyyOVTx7ZGKgjHMFV8usNIWPJL1tNHh7wSS5LTtEF6GEF+C1VGbkzZQlKcViza+Z2f czbFK8wB4D/XZdd8C1thrW1WBiaV0DSwxMtpPv1EijlbJeVIeSR8HnGkIjUmsHSt+2zT HvcIUJVrH1O+XDm50ptb81moKZt1dzyYKxGX/IhS1FGbJhBo4G/ZEWkg29qio0oGrjZC gRn1Tx1i+CHM2zl9N+ZfPl3xjE54RO9QoMO0S5iaQgSo5d+AU9wTC4RHs0iHgYJjQVSY YL6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1760035544; x=1760640344; h=content-transfer-encoding:mime-version:message-id:date:user-agent :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=0jJ96xGfYH9YmCqFaGgLXahbvelJ79KXl8RtWeyyy58=; b=BBSEUmsy3f1WVlqNpRG/cYN/3ygaItzF568JyyJTOQ/ILuuJhc5/rpciO5uQg4U/bx 7g26x2TnBpe01XzZwSLKcp1WWJizw/lnc763twCveVoi4wOUNln6BdlLZ38TFm2qplIT b7+StsaclZBIRDO6ZXs3mniEZHWcJ+WM4O2S5kAWSz+jzFI2MBqYmsjpJW6XyRO/Yt8O g8BF0NEpeS7rneAJKCeXgo/SKKw9MpnVeQbfgC9ItKYzBEZYFgiifuQg94+AAoLH69BB lo2rdWHP2eRHLWNXhohqvc1HU3t0t9Qn9nG1WBxXhlRSKm/6EA7sWLFuw4l9jCciHMml Dx8Q== X-Forwarded-Encrypted: i=1; AJvYcCXtq0wEiEpUyZGTo7Mkmeh6/vCxoahaO/qkwjUOmJka4QE+zb2qZwMzcP3MHbJz/TXhIF5biA==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yx/9xwx9z7KJAyNVcKgq50w3ch3lAOxS8aw4SvY1EIe59cRSL0l /uCxrf1F2CAQTVX7Kk70+beRLfPp1aVy/o/GUr9DWu4sf+Rw9gIHxLxXYca42g== X-Gm-Gg: ASbGncvka/xDspYpKHy99mrqHttPvHUIq1/7vFHy5KCSBklQWn3CVp4Xetzvoh9ryjJ EbxUr9NM5kKBfM3WvA/GsWpYazH1EiXRCK0WAiGzQp48dAJSBkab0uMxHpeZm53ArYDjLZ3bAzi YzahWJwRzqkZ4piqMjJiS0uU3iU57Zvj4m51ZH2FBLtJmvGuuLaTG14DNYLvsUhbIa/uxmJ4kaM 6a9D/MzljBZOhyTUNh44F924M1TV7sgtXI0cEMIK1PHUg1956sm4y4+fRq796GZ5C69a5V6SlDq AaqCAjJ46eda1Igi5dcKh4UvBUJtZgKIPoN/bHDMhjSyaUmtjq5AapygKtI5J3zd28K0dafZpgF FTvch8Dsb1anM7noTG3wHp7Jne/MaGQpq+Bz146ECBaFc X-Google-Smtp-Source: AGHT+IG80z6JxBXtxeKxGkixZjAcfrt1GAFqdzNl6nDOZtWsVY65ieRUeGjF6tssm6o1qD357tFnwg== X-Received: by 2002:a17:906:e20c:b0:b53:d97c:5203 with SMTP id a640c23a62f3a-b53d97c6304mr499414866b.42.1760035543756; Thu, 09 Oct 2025 11:45:43 -0700 (PDT) Received: from caladan ([31.177.112.212]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b55d900cc52sm32198666b.60.2025.10.09.11.45.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 09 Oct 2025 11:45:43 -0700 (PDT) From: Helmut Eller <eller.helmut@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <m2bjmg5omn.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <m2a5224pkr.fsf@HIDDEN> <87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN> <86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN> <87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN> <87frbszhwn.fsf@HIDDEN> <87ikgoczj2.fsf@HIDDEN> <m2frbs5www.fsf@HIDDEN> <m2bjmg5omn.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Thu, 09 Oct 2025 20:45:42 +0200 Message-ID: <875xcnzzft.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: 79584 Cc: 79584 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>, oliver.reiter@HIDDEN, 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 (-) On Thu, Oct 09 2025, Gerd M=C3=B6llmann wrote: > I meanwhile distrust AMS so deeply that I can't help it, and there is in > addition struct thread_state which is also allocated in AMS and so on. > I think I'll try replacing AMS in my Emacs. Maybe we're using the AMS pool incorrectly: when creating the immovable_ap, shouldn't there be an MPS_KEY_RANK =3D mps_rank_ambig() argument?
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 9 Oct 2025 10:57:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 09 06:57:34 2025
Received: from localhost ([127.0.0.1]:36363 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6oKz-0002Um-Tt
for submit <at> debbugs.gnu.org; Thu, 09 Oct 2025 06:57:34 -0400
Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]:56377)
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 1v6oKv-0002UT-F0
for 79584 <at> debbugs.gnu.org; Thu, 09 Oct 2025 06:57:30 -0400
Received: by mail-wr1-x432.google.com with SMTP id
ffacd0b85a97d-3ee12807d97so927211f8f.0
for <79584 <at> debbugs.gnu.org>; Thu, 09 Oct 2025 03:57:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1760007442; x=1760612242; 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=uNgMI4X2WAqF3IdJ6mfXW5BYx9O4glqL3PthXWmnJsw=;
b=FFHPHxXaDGP0/ymKdruLEJTKyVIBPC/E3fD3d7S1qeVzrozS0c2I9W4Hv+3amh5CHR
m51K7eq+Nmd4XAEksHVOzfeBJidBrodjR1teueW6OZqx1MQFtvf4uJ7YQJUYGLHnAF8T
liNB/jKxzCLfJKWMX+WXvS5UL4Ffx/8m7Rnc0DlFdJylrMzufX2D/Q8y/Zzw6AtwodR3
RmfsOoiu36MfTTNrR5W3USaq4DH7Oou/NmHdVeWlnoJx/FE6pfHdUjifxLZBq16sO4W+
Oycmls60saYTiBO9FtuM2oHrAWjl1dhlawX1gyDLysHTkPZcLCw8ntt+di8CwWxcT9FD
Neng==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1760007442; x=1760612242;
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=uNgMI4X2WAqF3IdJ6mfXW5BYx9O4glqL3PthXWmnJsw=;
b=VU3x13ubd4O/8JlaGq2dkK/PtdOD809B7lF/HKHgRTk2N9dcw29Zpa145tySo/rx/C
LTnbqfgAOZG/zG9lPBpxp6z8zpyhsbFaZwpqCJHB5ojpvaf4G5W2DbYm84f7urDoExvO
NuL3h14vJ1uDrTX5P0Ata35dPWCLbUDakg0jhK5D7gGGfZ9u70sDz2eI1oyjyVU/a3SB
5t1oBpqAEY4d/hhY4ro0XO5C2eODzeEsgDgvjV48B4tX8VhVhTfehAQ22pOGozO9SSRM
8aDDRSV5hIWQGQm3yE1L9gQGuhYKKITLtX/tOwVRZtcC4FoBatnlUDmN1dYuoGp4/keS
MOMw==
X-Forwarded-Encrypted: i=1;
AJvYcCUoTmzvOYoPDtqkeq6Sg4N/H/i6/0woS7iDUQ1/b+DlC1EjApfNKs40bNDuqZUjVOOqyrzVsw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yz9jlkBkUrsxxav6p0rwufa2I2vKqXKNiSo2yaUKOwEBXnR8Myb
0+0057JvKqQLFDUvOzdyZcT3ZP2Z6/DAh3m4V9tV6ypnNplCQZjjm2lqIBVD1g==
X-Gm-Gg: ASbGnctemAyb3fuDWZiMW5VsTvIyOsIwcHZhwu+T1sgWEdCi7lQqvj2TnLyhO6ss+Yk
994FKGw6XIRbQapdsc29iRxfNgWza2XKHRccpXHBBund438HM7j1pNHMWxYR603nF+QIMEjVjL3
2E/Jc36Y8P1L+0dtstd5s+ljvXetR9hAgeoUPm5xYPplMYQHGSH4oTKlHhOcnMy6VnFqKrX5ISq
Me5n48fZIea6PNaHcdLYHCHMVmNJgaOQKX37nham2WJ/l+mpx+UsgFy9conFtZlX7vg8gs5ZWNK
lmPO1IXvZ0HPsz9fknpLsEFYi7dYN6n4g3+/0HpQ0LgUiRZBWN0NvcFMJyosx4nSN20gxPzJDWZ
8lguEDYzYzK1swnMEoztg+H/3CSAEsrBCPTFUtxSMWwz6PqiQlwp1ckwiqph2PbFY2sqi3oWOZb
1+jmXz86zWUf31A5UolnIXhPr3mtIXrOg01yWCrFZXxA6s6iNjQdbXDwo=
X-Google-Smtp-Source: AGHT+IEg3Gl0FqIRBpG4bg0GUKYGzHdl0DT+m2UqHSYjBjNaHy54bIa/Vl8ZnT2QU0U89CxHUJefog==
X-Received: by 2002:a05:6000:401f:b0:3e9:a1cb:ea8f with SMTP id
ffacd0b85a97d-4267260e2famr5065047f8f.52.1760007441627;
Thu, 09 Oct 2025 03:57:21 -0700 (PDT)
Received: from pro4 (p200300e0b70e3c00d4a11efba4f5857e.dip0.t-ipconnect.de.
[2003:e0:b70e:3c00:d4a1:1efb:a4f5:857e])
by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-4255d8a6b5csm34246495f8f.5.2025.10.09.03.57.20
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 09 Oct 2025 03:57:21 -0700 (PDT)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <m2frbs5www.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN>
<86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
<87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN>
<87frbszhwn.fsf@HIDDEN> <87ikgoczj2.fsf@HIDDEN>
<m2frbs5www.fsf@HIDDEN>
Date: Thu, 09 Oct 2025 12:57:20 +0200
Message-ID: <m2bjmg5omn.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: 79584
Cc: oliver.reiter@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
Helmut Eller <eller.helmut@HIDDEN>, 79584 <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:
> Pip Cet <pipcet@HIDDEN> writes:
>
>> "Helmut Eller" <eller.helmut@HIDDEN> writes:
>
>> Thanks for spotting this! Will try to come up with an improved patch.
>
> Maybe this could be helpful? Incomplete and so on, but that is basically
> what I would do for pins if replacing AMS with AMC+pinning. Untested of
> course.
I meanwhile distrust AMS so deeply that I can't help it, and there is in
addition struct thread_state which is also allocated in AMS and so on.
I think I'll try replacing AMS in my Emacs.
Very first patch, 15 minutes old, ported back to feature/igc looks like
this:
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment;
filename=0001-Replace-AMS-pool-for-immovable-objects.patch
From b3e5228445ac7933b553de1c25bad5b6e6777711 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Gerd=20M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Date: Thu, 9 Oct 2025 12:32:51 +0200
Subject: [PATCH] Replace AMS pool for immovable objects
* src/igc.c (struct igc_pins): New.
(struct igc): Add member pins.
(pin, unpin): New functions.
(igc_thread_remove): Unpin thread_state.
(igc_alloc_global_ref): Pin allocated global ref.
(igc_free_global_ref): New function.
(make_pool_ams): Remove.
(make_igc): Make immovable pool and AMC pool.
* src/igc.h (igc_free_global_ref): Declare.
* src/emacs-module.c (module_free_global_ref): Call
igc_free_global_ref.
* src/lisp.h (struct thread_state): Add member pin_index.
* src/thread.h (GCALIGNED_STRUCT): Add member pin_index.
---
src/emacs-module.c | 7 +++++-
src/igc.c | 63 ++++++++++++++++++++++++++++++++++++++++------
src/igc.h | 4 +++
src/lisp.h | 4 +++
src/thread.h | 1 +
5 files changed, 70 insertions(+), 9 deletions(-)
diff --git a/src/emacs-module.c b/src/emacs-module.c
index f3a92500f62..c6a528baf6a 100644
--- a/src/emacs-module.c
+++ b/src/emacs-module.c
@@ -471,7 +471,12 @@ module_free_global_ref (emacs_env *env, emacs_value global_value)
struct module_global_reference *ref = XMODULE_GLOBAL_REFERENCE (value);
eassert (0 < ref->refcount);
if (--ref->refcount == 0)
- hash_remove_from_table (h, obj);
+ {
+ hash_remove_from_table (h, obj);
+#ifdef HAVE_MPS
+ igc_free_global_ref (ref);
+#endif
+ }
}
MODULE_INTERNAL_CLEANUP ();
diff --git a/src/igc.c b/src/igc.c
index 35e0ec3c596..713ab347e94 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -34,7 +34,6 @@
#include "../mps/code/mps.h"
#include "../mps/code/mpsavm.h"
#include "../mps/code/mpscamc.h"
-#include "../mps/code/mpscams.h"
#include "../mps/code/mpscawl.h"
#include "../mps/code/mpslib.h"
#ifdef __clang__
@@ -929,6 +928,17 @@ IGC_DEFINE_LIST (igc_root);
typedef struct igc_thread igc_thread;
IGC_DEFINE_LIST (igc_thread);
+struct igc_pins
+{
+ ptrdiff_t capacity;
+ ptrdiff_t used;
+ ptrdiff_t free;
+ union {
+ void *obj;
+ ptrdiff_t next_free;
+ } *entries;
+};
+
/* The registry for an MPS arena. There is only one arena used. */
struct igc
@@ -959,10 +969,44 @@ IGC_DEFINE_LIST (igc_thread);
/* Registered threads. */
struct igc_thread_list *threads;
+
+ struct igc_pins pins;
};
static bool process_one_message (struct igc *gc);
+static ptrdiff_t
+pin (struct igc *gc, void *obj)
+{
+ struct igc_pins *p = &gc->pins;
+ if (p->used == p->capacity)
+ {
+ p->entries = igc_xpalloc_ambig (p->entries, &p->capacity,
+ 1, -1, sizeof *p->entries);
+ for (ptrdiff_t i = p->used; i < p->capacity; ++i)
+ {
+ p->entries[i].next_free = p->free;
+ p->free = i;
+ }
+ }
+
+ const ptrdiff_t e = p->free;
+ p->free = p->entries[e].next_free;
+ p->entries[e].obj = obj;
+ ++p->used;
+ return e;
+}
+
+static void
+unpin (struct igc *gc, void *obj, ptrdiff_t i)
+{
+ struct igc_pins *p = &gc->pins;
+ eassert (p->entries[i].obj == obj);
+ p->entries[i].next_free = p->free;
+ p->free = i;
+ --p->used;
+}
+
/* The global registry. */
static struct igc *global_igc;
@@ -3301,6 +3345,7 @@ igc_thread_remove (void **pinfo)
{
struct igc_thread_list *t = *pinfo;
*pinfo = NULL;
+ unpin (global_igc, t->d.ts, t->d.ts->pin_index);
destroy_root (&t->d.stack_root);
destroy_root (&t->d.specpdl_root);
destroy_root (&t->d.bc_root);
@@ -4309,8 +4354,15 @@ igc_alloc_global_ref (void)
struct Lisp_Vector *v
= alloc_immovable (header_size + nwords_mem * word_size, IGC_OBJ_VECTOR);
XSETPVECTYPESIZE (v, PVEC_MODULE_GLOBAL_REFERENCE, 0, nwords_mem);
+ ((struct module_global_reference *) v)->pin_index = pin (global_igc, v);
return v;
}
+
+void
+igc_free_global_ref (struct module_global_reference *r)
+{
+ unpin (global_igc, r, r->pin_index);
+}
#endif
Lisp_Object
@@ -4395,6 +4447,7 @@ igc_alloc_pseudovector (size_t nwords_mem, size_t nwords_lisp,
scanning the bytecode stack (scan_bc), and making thread_state
immovable simplifies the code. */
v = alloc_immovable (client_size, IGC_OBJ_VECTOR);
+ ((struct thread_state *) v)->pin_index = pin (global_igc, v);
}
else
v = alloc (client_size, IGC_OBJ_VECTOR);
@@ -5070,12 +5123,6 @@ make_pool_amc (struct igc *gc, mps_fmt_t fmt)
return make_pool_with_class (gc, fmt, mps_class_amc (), NULL);
}
-static mps_pool_t
-make_pool_ams (struct igc *gc, mps_fmt_t fmt)
-{
- return make_pool_with_class (gc, fmt, mps_class_ams (), NULL);
-}
-
static mps_pool_t
make_pool_awl (struct igc *gc, mps_fmt_t fmt, mps_awl_find_dependent_t find_dependent)
{
@@ -5108,7 +5155,7 @@ make_igc (void)
gc->weak_hash_fmt = make_dflt_fmt (gc);
gc->weak_hash_pool = make_pool_awl (gc, gc->weak_hash_fmt, weak_hash_find_dependent);
gc->immovable_fmt = make_dflt_fmt (gc);
- gc->immovable_pool = make_pool_ams (gc, gc->immovable_fmt);
+ gc->immovable_pool = make_pool_amc (gc, gc->immovable_fmt);
root_create_charset_table (gc);
root_create_buffer (gc, &buffer_defaults);
diff --git a/src/igc.h b/src/igc.h
index 13b5646f387..60690ee0692 100644
--- a/src/igc.h
+++ b/src/igc.h
@@ -80,7 +80,11 @@ #define EMACS_IGC_H
void igc_remove_all_markers (struct buffer *b);
void igc_resurrect_markers (struct buffer *b);
Lisp_Object igc_alloc_symbol (void);
+#ifdef HAVE_MODULES
void *igc_alloc_global_ref (void);
+void igc_free_global_ref (struct module_global_reference *ref);
+#endif
+Lisp_Object igc_alloc_marker_vector (ptrdiff_t len, Lisp_Object init);
struct Lisp_Buffer_Local_Value *igc_alloc_blv (void);
void *igc_alloc_handler (void);
diff --git a/src/lisp.h b/src/lisp.h
index 391c5bef6e9..9a51a75ffed 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -6356,6 +6356,10 @@ maybe_gc (void)
/* Pseudovector header, must come first. */
struct vectorlike_header header;
+# ifdef HAVE_MPS
+ ptrdiff_t pin_index;
+# endif
+
/* Holds the emacs_value for the object. The Lisp_Object stored
therein must be the same as the hash key. */
struct emacs_value_tag value;
diff --git a/src/thread.h b/src/thread.h
index f50a627cb33..895c4944f29 100644
--- a/src/thread.h
+++ b/src/thread.h
@@ -228,6 +228,7 @@ #define getcjmp (current_thread->m_getcjmp)
# ifdef HAVE_MPS
void *gc_info;
+ ptrdiff_t pin_index;
# endif
} GCALIGNED_STRUCT;
--
2.51.0
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 9 Oct 2025 07:58:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 09 03:58:52 2025
Received: from localhost ([127.0.0.1]:35702 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6lY4-0007f4-2l
for submit <at> debbugs.gnu.org; Thu, 09 Oct 2025 03:58:52 -0400
Received: from mail-wm1-x32b.google.com ([2a00:1450:4864:20::32b]:47262)
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 1v6lXk-0007eX-O3
for 79584 <at> debbugs.gnu.org; Thu, 09 Oct 2025 03:58:36 -0400
Received: by mail-wm1-x32b.google.com with SMTP id
5b1f17b1804b1-46e34052bb7so8066665e9.2
for <79584 <at> debbugs.gnu.org>; Thu, 09 Oct 2025 00:58:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1759996705; x=1760601505; 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=X4OfwO6wes3sWFx/XqjVRKyOvFF0WQ1mrJmXEZcwTYA=;
b=VWYRHoXVvkGPA3lOho2Ys3JQL3mEkEo6W3s9pNnPh3a6VWmLtUhL3RSXFnWoX8x2P5
6/KV1uo2G7QRSIiRPzQrZENNYZCMCP7VMOPT2HKWPtNy3jtCIkgWmLs0tTtYj8dDIlS9
YOP7HZze61LuGsMUd6qskn10TkhrNFOxv1bPgC1XaVg0Qc7dxxTnVZtBYbr54vCy88qZ
kL5qokSgZxJhF9hLHb0vln6FNVGPGzKx5ZMWM4wclR/pBSGPUgvOrYPe0kBAhiDibB/r
giscdKGukKJDEBq5vaB4da/6R+Ns/i5uiSJ908LI/eofeXBQDHHrO3UH4RpV2CdNoUvd
0ZUA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1759996705; x=1760601505;
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=X4OfwO6wes3sWFx/XqjVRKyOvFF0WQ1mrJmXEZcwTYA=;
b=Y08qYAYlDg5gQBeivdLvuWIU+NAsv8lSAOSYbM9wHHALVyU9M+Z8pUUs4u48zBoqLO
91a/aUd+9BfIv0JJRbCSVGtTi+vjNjYmJK/j1dQqw9D8wGfE+dPD2+4XBLtPGSRHJmQ4
X/Ua45QMVJWoy725d48vKb62+bPN3VwlTYoR+CCHFCx5s1eV2o2Y6wYdVG5l18zKpaRI
hNyHn2IX9CEfk/ykl70jeHGqiuamwQOPXgXmAvm7PRuTGC3Iu1GolbgJTXwmba+piiBH
Z6P1iaJWuAQyy7q112JQuLsK/EB185GQgvxPqmLBZ2wgNW9PZMRSOHsPoIVGXvro5C+b
kLhw==
X-Forwarded-Encrypted: i=1;
AJvYcCVhnqX47APQgClIy0MVKb5zabcMaeF4qNbUD5M6Z1WrAy31ud8g/X/OCuF/SXMmuUCkBgBqpw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzHA3nABNbCO9PWAVcj+8+dNQGitPnxh2hjv+FzGeufck47yz6k
Js0Q5uDa18yxkAef8TSUx3agzx3TkeoWnzawwwhOL3Aa/0eBd2vjsmGB559Uug==
X-Gm-Gg: ASbGncs4tfd2cXGGhxPFNm/sq9WoEGPqKMbJ4f9XzaKc+aH4nS7IoF0yHUYnsQ8FemZ
PHNL14Gp+JLE+uqv9cQGDw9yL9khgGkIGJneiUmi/OngSTUlZcbrIMm3/deMOh4EBprDd+JyJQh
IbQ6uTiv4uliTSCn17BS2UjbPfNFGoMnj2Oz6Pr/EqiGCduBVAx8jxOVre1B4PvT8oqep9rQL3j
+Vwv/GL/W0S74qfTwMZCpb1Z8ZFg0wyQBLQIfjTz/pNPuWg51LUFEmIlCSJxBSYFfe4+PNyvxgu
XuIxXbGeXk0MulxY3MqzS/NCo5KBdraGmBAv6nMFRxFaVQkKpKEx+5SAP0innnHf9e3xGS7Wa6Z
YFrdPaA2ZVRftsvu5HY+RrHAizYl4WGvFjBJLRJF6kKOV34WDjkDKgcqARjjQeUVN1FaCtfzUda
Dt3CvLFhvVcdtpUazP16vEe5ND3Wm6pKf4GZP0FhWiSwaSkod2aooIjEY=
X-Google-Smtp-Source: AGHT+IHK59uXUFn+zojxU9MkpniKZkVnehC504Li93S1WaKajeYiq/rqZthjlS7zMJW7bzN4tOMipw==
X-Received: by 2002:a05:6000:2501:b0:3fc:195e:e180 with SMTP id
ffacd0b85a97d-42666ab88f0mr3098716f8f.9.1759996705076;
Thu, 09 Oct 2025 00:58:25 -0700 (PDT)
Received: from pro4 (p200300e0b70e3c00d4a11efba4f5857e.dip0.t-ipconnect.de.
[2003:e0:b70e:3c00:d4a1:1efb:a4f5:857e])
by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-4255d8f02a8sm33819404f8f.39.2025.10.09.00.58.24
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 09 Oct 2025 00:58:24 -0700 (PDT)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <87ikgoczj2.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN>
<86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
<87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN>
<87frbszhwn.fsf@HIDDEN> <87ikgoczj2.fsf@HIDDEN>
Date: Thu, 09 Oct 2025 09:58:23 +0200
Message-ID: <m2frbs5www.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: 79584
Cc: oliver.reiter@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
Helmut Eller <eller.helmut@HIDDEN>, 79584 <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
Pip Cet <pipcet@HIDDEN> writes:
> "Helmut Eller" <eller.helmut@HIDDEN> writes:
> Thanks for spotting this! Will try to come up with an improved patch.
Maybe this could be helpful? Incomplete and so on, but that is basically
what I would do for pins if replacing AMS with AMC+pinning. Untested of
course.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment; filename=pins.patch
Content-Description: pin registry
diff --git a/src/igc.c b/src/igc.c
index 7551ebddab6..bed13d77c0b 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -926,6 +926,17 @@ IGC_DEFINE_LIST (igc_root);
typedef struct igc_thread igc_thread;
IGC_DEFINE_LIST (igc_thread);
+struct igc_pins
+{
+ ptrdiff_t capacity;
+ ptrdiff_t used;
+ ptrdiff_t free;
+ union {
+ void *obj;
+ ptrdiff_t next_free;
+ } *entries;
+};
+
/* The registry for an MPS arena. There is only one arena used. */
struct igc
@@ -956,10 +967,43 @@ IGC_DEFINE_LIST (igc_thread);
/* Registered threads. */
struct igc_thread_list *threads;
+
+ struct igc_pins pins;
};
static bool process_one_message (struct igc *gc);
+static void
+pin (struct igc *gc, void *obj)
+{
+ struct igc_pins *p = &gc->pins;
+ if (p->used == p->capacity)
+ {
+ p->entries = igc_xpalloc_ambig (p->entries, &p->capacity,
+ 1, -1, sizeof *p->entries);
+ for (ptrdiff_t i = p->used; i < p->capacity; ++i)
+ {
+ p->entries[i].next_free = p->free;
+ p->free = i;
+ }
+ }
+
+ const ptrdiff_t e = p->free;
+ p->free = p->entries[e].next_free;
+ p->entries[e].obj = obj;
+ ++p->used;
+}
+
+static void
+unpin (struct igc *gc, void *obj, ptrdiff_t i)
+{
+ struct igc_pins *p = &gc->pins;
+ eassert (p->entries[i].obj == obj);
+ p->entries[i].next_free = p->free;
+ p->free = i;
+ --p->used;
+}
+
/* The global registry. */
static struct igc *global_igc;
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 9 Oct 2025 07:22:41 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 09 03:22:41 2025
Received: from localhost ([127.0.0.1]:35634 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6kz2-0005ti-Jh
for submit <at> debbugs.gnu.org; Thu, 09 Oct 2025 03:22:41 -0400
Received: from mail-10629.protonmail.ch ([79.135.106.29]:53829)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1v6kyT-0005rk-A7
for 79584 <at> debbugs.gnu.org; Thu, 09 Oct 2025 03:22:09 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1759994517; x=1760253717;
bh=1dewOSgswOxlO26uIBLiRhaL/O2bScI/isP/a1SKWiQ=;
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;
b=IpAMQSr21KxKQunBiXUom+keh5rnHKsf0rl7/bxZHv8phTsCC8aXjaAkItHTn1ooM
MelDI8DenNGeCTtsMpsg0JLzg2D/medx77j0I2NqSOcDwfs/Xo3nHR1j12he1S/dFm
0tslUzhwV+WZRyv1ogGSyBxyCQL5EU615YmEbYVqxiHGnsAV6AhY4SNN41n4IhSA+l
YJCSabiBHt4cXOD0LtRQuji1JcY2gblTEniGzcSlb6nLcFcliHPXLfpUFxh16g9sk8
YopauVQAZBPCpOIQCDa8/H8Hc0i+oO4Uulza6rwRfX48vGgSMRsNhFP9Y0FnTzSy1z
Lo7qS5Wc+FcJg==
Date: Thu, 09 Oct 2025 07:21:51 +0000
To: Helmut Eller <eller.helmut@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
Message-ID: <87ikgoczj2.fsf@HIDDEN>
In-Reply-To: <87frbszhwn.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN>
<86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
<87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN>
<87frbszhwn.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: f41a0f4c65f92cf92965253a827ac59ec89ac6d3
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: 79584
Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>,
Eli Zaretskii <eliz@HIDDEN>, oliver.reiter@HIDDEN,
79584 <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 (-)
"Helmut Eller" <eller.helmut@HIDDEN> writes:
> On Wed, Oct 08 2025, Pip Cet wrote:
>
>> Pip Cet <pipcet@HIDDEN> writes:
>>
>>> I suggested the hash table index, but same idea.
>>
>> This seems to work, at least. No need to recompile the module, either.
>
> Is there some guarantee that hash table index stays the same when the
> hash table grows?
There is, but we should add a comment here just to make sure we know
what to change if and when the hash table resizing code changes
(allowing hash tables to shrink would certainly change the index).
(I implemented shrinking hash tables a while back, and there are quite a
few places that need changing. IIRC HASH_KEY just has to go away
entirely and then the code will fail to compile until it's fixed.)
I'm not sure whether having two hash tables would be better: one to map
objects to fixnums, and one to map fixnums to objects. That would
improve detection of stale references (hash table index values get
reused; our fixnums wouldn't be), and it would avoid relying on hash
table internals. In fact, I believe it would allow us to stop
considering module global references as pvecs entirely, and that seems a
lot cleaner.
> [...]
>> #ifdef HAVE_MODULES
>> -void *
>> +struct module_global_reference *
>> igc_alloc_global_ref (void)
>> {
>> size_t nwords_mem =3D VECSIZE (struct module_global_reference);
>> - struct Lisp_Vector *v
>> - =3D alloc_immovable (header_size + nwords_mem * word_size, IGC_OBJ_=
VECTOR);
>> + struct module_global_reference *v
>> + =3D xzalloc (sizeof *v);
>> XSETPVECTYPESIZE (v, PVEC_MODULE_GLOBAL_REFERENCE, 0, nwords_mem);
>> return v;
>> }
>
> How does this work? The module_global_reference is malloced and then
> placed in a Lisp_Hash_Table?
Correct. It assumes MALLOC_IS_LISP_ALIGNED.
> Why does MPS scan the malloced object?
It doesn't. fix_global_ref is still there, but it shouldn't be called,
and doesn't need to be.
Thanks for spotting this! Will try to come up with an improved patch.
Pip
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 9 Oct 2025 06:56:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 09 02:56:59 2025
Received: from localhost ([127.0.0.1]:35576 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6kaB-0004ZR-41
for submit <at> debbugs.gnu.org; Thu, 09 Oct 2025 02:56:59 -0400
Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]:42047)
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 1v6ka5-0004Z9-GK
for 79584 <at> debbugs.gnu.org; Thu, 09 Oct 2025 02:56:54 -0400
Received: by mail-ed1-x530.google.com with SMTP id
4fb4d7f45d1cf-62fca216e4aso1669523a12.0
for <79584 <at> debbugs.gnu.org>; Wed, 08 Oct 2025 23:56:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1759993006; x=1760597806; 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=Nz/Nq8dtuzKGikdRfdmBmFz3plf7XZKZyOctH4W2R00=;
b=YRZSnfRn0h4ovXbFFsL7iwlxmOqe0y4TYBEVdeoJ1McBfkFraLr5sHSuGp6Rdas/sa
30+yGcX9LN5lrPak1NbpjvYyB8WzTzj/Dtb9xLrdRFHh8tchta/vC1X/xK6/1Bu6zELz
35xG+Ou5yU95UJMjsmWJwLLJTFC7KszUpaIoSqf3MUn6HEv1mlJ55nWxDww31++b7m4H
lP3iLFJ2XR7l37467au1iTXc9lQkQaUZpi0MB87dtyqXliD2gyUYOY/r5EbuPwEV/RDS
f9OrE9TV55+RrwnyWsKbcz3a8EGZphCob2gcf34Wg4OwwSg8nMbZrKDnvgthu09stx+r
uWjQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1759993006; x=1760597806;
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=Nz/Nq8dtuzKGikdRfdmBmFz3plf7XZKZyOctH4W2R00=;
b=UDBbUsNrtlDtI4MMP/G4fYq6Rkllfbjl2jELEy/SJxoe9R1aHe1CK/aD6raWL5fc5k
Z4BFx7DARIYzIQv/DFJRlIeBOaO9vq/jk2YBOzNX1dCX29qN1YyKAYLtbV6qbw7xkELh
Sam7q40zj+sy3ywo+EF3ZdBMwApvL3Rw8/PiPzqcJwi4OLDpMXV5ImCnRGPNsysH24I5
UPaIvUU4Ns+eC3fkTHvd4IcVPbbKatS0WJG8zX70ViH9n3JzcmGwFgo18zM5mMhloXMQ
Rwfd4FUKU5aGgIl/Q5mPAi7QJzVtzVHk4OR8aoV2q0e+rOkuIZrjOtQ11/IWsf/8c8qI
Gr4A==
X-Forwarded-Encrypted: i=1;
AJvYcCUZK1cU/6PTLpxOhESwXkG5/vQda/ozgd1FKVdI3NWqopoSbYj+2bGRfCII61y8cuNQNdgl7A==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxDDv6iL4AWX5yEMXIMDg8I5cn4tiYpp+zJM3O08LLLKT+qEOob
FYp5PuI9eLhvKVeOyNe0joZIwwti96xn7nBUupslZDl2xr34VhUnXYYWUruX7A==
X-Gm-Gg: ASbGncvxzTI0vBoBGW0Vk+98ilI2QvKf/HeQJEh2ow/9Vp3991SNXsVfGzYZUSI8U7h
ZZwCM9IAm1m6reXY1zXAM1tH80LZzOiMP51fzrX5ga7ingwY90uKum4HowMkQPCRKgxL/3nzhf/
3fs16s9YMDL9DZhJhSlZNiI6r4BfpQWoM9ywmWfpfN/wQnGl7MUwPSQDsDRoI8mtmFnstlYAlzT
Rm1RuYKfaJ9QnjzeL44uSdcxqwLVNID1GDYkyjJB5o7SxxHiuV8zEoE4AcdJemjrbMmSg0TSH6Q
g/pnEV3wNFMLBUEfzuP4CpwwEKpA3qi76stXclISMgwxefti7prKEbpbEfSJINey4JPnD8obrRl
BY7qq4K6IVVjAy02HzluFDJgnygIwDUSiin9D5Df4hT0JEz0KvAvEYLiPGPgbwoWkI/9axZBZoM
h4gehqonW4xDwCaZVlDgFRBTuHd/yP/WhoGRqfznQ0/zLjTQ4XCN+0f24=
X-Google-Smtp-Source: AGHT+IFnbWaAe4k2rzzI5LoltlY2MSbvDHNNhtQbhvD31xrBA7vJpQKF5n6u0GarOpZUZvEldnLjIA==
X-Received: by 2002:a17:907:d412:b0:b3b:478:515f with SMTP id
a640c23a62f3a-b4f43105684mr1048395266b.22.1759993006389;
Wed, 08 Oct 2025 23:56:46 -0700 (PDT)
Received: from pro4 (p200300e0b70e3c00d4a11efba4f5857e.dip0.t-ipconnect.de.
[2003:e0:b70e:3c00:d4a1:1efb:a4f5:857e])
by smtp.gmail.com with ESMTPSA id
a640c23a62f3a-b4865e7e8b7sm1836415866b.40.2025.10.08.23.56.45
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 08 Oct 2025 23:56:45 -0700 (PDT)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Helmut Eller <eller.helmut@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <87frbszhwn.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86jz17cku0.fsf@HIDDEN>
<87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN>
<86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
<87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN>
<87frbszhwn.fsf@HIDDEN>
Date: Thu, 09 Oct 2025 08:56:45 +0200
Message-ID: <m2jz145zrm.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: 79584
Cc: 79584 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>,
oliver.reiter@HIDDEN, 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 (-)
Helmut Eller <eller.helmut@HIDDEN> writes:
> On Wed, Oct 08 2025, Pip Cet wrote:
>
>> Pip Cet <pipcet@HIDDEN> writes:
>>
>>> I suggested the hash table index, but same idea.
>>
>> This seems to work, at least. No need to recompile the module, either.
>
> Is there some guarantee that hash table index stays the same when the
> hash table grows?
>
> [...]
>> #ifdef HAVE_MODULES
>> -void *
>> +struct module_global_reference *
>> igc_alloc_global_ref (void)
>> {
>> size_t nwords_mem = VECSIZE (struct module_global_reference);
>> - struct Lisp_Vector *v
>> - = alloc_immovable (header_size + nwords_mem * word_size, IGC_OBJ_VECTOR);
>> + struct module_global_reference *v
>> + = xzalloc (sizeof *v);
>> XSETPVECTYPESIZE (v, PVEC_MODULE_GLOBAL_REFERENCE, 0, nwords_mem);
>> return v;
>> }
>
> How does this work? The module_global_reference is malloced and then
> placed in a Lisp_Hash_Table? Why does MPS scan the malloced object?
>
> Helmut
Yes. good question, and in a way the same when the global_ref is in AMS. How
gets the reference X contained in the global_ref when X moves when there
is no read-barrier on AMS.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 9 Oct 2025 06:52:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 09 02:52:24 2025
Received: from localhost ([127.0.0.1]:35558 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6kVk-0004Mr-1D
for submit <at> debbugs.gnu.org; Thu, 09 Oct 2025 02:52:24 -0400
Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:57608)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>)
id 1v6kVe-0004MC-5u
for 79584 <at> debbugs.gnu.org; Thu, 09 Oct 2025 02:52:19 -0400
Received: by mail-wm1-x333.google.com with SMTP id
5b1f17b1804b1-46e48d6b95fso5128595e9.3
for <79584 <at> debbugs.gnu.org>; Wed, 08 Oct 2025 23:52:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1759992731; x=1760597531; 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=Alue/de6jaXP0XwHzm9/4PZzXSNgiXMGsX6SbUJoNYU=;
b=FBdBdTQeWz82NfJsc7EzlK7Eru47REr6NL3dt7Q/p/4aJQPurws7SnVVkEdtNA8Xed
bzVV9KSZsX2YGN53wF9MnHAM5rvHjcUUOcBoLgEABIfTUuHsn0Uc/maYEQMfJ+Pg8G4z
IaZvgYaDWzJTNXBx0Lr72JxXKs3BeiG3GVXUO6TrEUgoPsvC38KBhsl2G5cxizSEb0xn
qAhShrzSPRfzeB76SAJZrfy8/hbcoXedw/x2nV93OsJLwro2rHht4OWSwstRSl3W/1oe
99fryUjBPP+TzoINTkKnnsnN9HKfL8yNiqecjRbGfZ2y50hadquAlfjOs23IFsjBhhNe
g1eA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1759992731; x=1760597531;
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=Alue/de6jaXP0XwHzm9/4PZzXSNgiXMGsX6SbUJoNYU=;
b=JhmMiJ363yIu+EFec9aNrTOenYumL0elAOawbvcqoL+j7I2lBKO3OWv02YCsydeIR8
HODkmj+n7O4QLBBTiXVMtU7sHdOSIuqhHjlWbohRM3b/BhHHaOoV+mBJOuYOQN/0kN7y
0dJzlnQY7rswbUFcL4qUj0KnmaSI8zvrTAW7BLFzRap7J8xey/nAJwnfKVR7dUQTI6no
HyaKuHRg3/VDdOVX8fOlLX+lgQgg5AuMIPLlSA1cx0z8gtyeZNxyRbUvp62IOWqAce/U
oyu+JIK9H71GAWV+OK523ztYqSO9dWqYd/3YBLcdD9lYOATC9d9CSN0EQ8PNJbq2lWvs
ZYXw==
X-Forwarded-Encrypted: i=1;
AJvYcCXry8c0FD3RCdQB8QclsRQVoUvs9CXodL6WHtf5Hz9YfXcBinpAHuMHLIbxp4OA7Phu+q68EA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzoOnKRoNQssFxFmlSzVwddQSVXn55qA6gEJkPpcAejFWmYcL1O
RlAIn7yoUqjWJFgwu53GSoAeZl4UpeUwEVIUvpJXddrf/+tZst/yn6r3uGrBdA==
X-Gm-Gg: ASbGncuAkmVQMMKKXZ5oBnMfvKFQDQoeL/F2YZQUzNP6wls7G2r7ZvcXg+7fuVMirIQ
y5xCmw1zE0nRw4fA/6moqZOs9NiS2DcwC+hsICczbOqDZvYPZAWu3ffI+d/ml9/sG6TXY09pIko
ew/kc0kdxbjIXWga4nzP7b1XgEXamYQTbTlFPS8zAB/sSwJYaeK4LLZdgITwLTIc1bHK1LZJb1r
zjgoODP4hQhLNtC/Oj9yxI+GEuffp65/PIWa1BhUFnqN2QZAkdDVSXhgQGVpJeinujTr2Rh2GZT
SBP5o4/Ha1QerXBR1O+sLKVb9/C++9FD9m6n5oHzBTZxRYkng+G4h+wJM7oV0p5rRf++XNkxwnX
7Nu/olGxpYYibb4QDZqhmhGiv62nyVq/yslwfNBO5xoZZ
X-Google-Smtp-Source: AGHT+IEbpzLGHgw9YC5numzUG/E4zQc0hYEmsZ1DV6cK5NmQ0wlNC8nAqw3VGuyJNCoeI8ZOp/nXKA==
X-Received: by 2002:a05:600c:529a:b0:46e:4c7c:5140 with SMTP id
5b1f17b1804b1-46fa9af30bfmr42876125e9.18.1759992730506;
Wed, 08 Oct 2025 23:52:10 -0700 (PDT)
Received: from caladan ([31.177.112.212]) by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-46fab3e3520sm31527795e9.2.2025.10.08.23.52.09
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 08 Oct 2025 23:52:10 -0700 (PDT)
From: Helmut Eller <eller.helmut@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <87o6qhcjzy.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86jz17cku0.fsf@HIDDEN>
<87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN>
<86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
<87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN>
Date: Thu, 09 Oct 2025 08:52:08 +0200
Message-ID: <87frbszhwn.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: 79584
Cc: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>,
Eli Zaretskii <eliz@HIDDEN>, oliver.reiter@HIDDEN,
79584 <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 Wed, Oct 08 2025, Pip Cet wrote:
> Pip Cet <pipcet@HIDDEN> writes:
>
>> I suggested the hash table index, but same idea.
>
> This seems to work, at least. No need to recompile the module, either.
Is there some guarantee that hash table index stays the same when the
hash table grows?
[...]
> #ifdef HAVE_MODULES
> -void *
> +struct module_global_reference *
> igc_alloc_global_ref (void)
> {
> size_t nwords_mem = VECSIZE (struct module_global_reference);
> - struct Lisp_Vector *v
> - = alloc_immovable (header_size + nwords_mem * word_size, IGC_OBJ_VECTOR);
> + struct module_global_reference *v
> + = xzalloc (sizeof *v);
> XSETPVECTYPESIZE (v, PVEC_MODULE_GLOBAL_REFERENCE, 0, nwords_mem);
> return v;
> }
How does this work? The module_global_reference is malloced and then
placed in a Lisp_Hash_Table? Why does MPS scan the malloced object?
Helmut
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 9 Oct 2025 06:38:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 09 02:38:09 2025 Received: from localhost ([127.0.0.1]:35485 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6kHw-0003Xa-R0 for submit <at> debbugs.gnu.org; Thu, 09 Oct 2025 02:38:09 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57802) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1v6kHm-0003Wr-RL for 79584 <at> debbugs.gnu.org; Thu, 09 Oct 2025 02:38:00 -0400 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 1v6kHf-0003iU-1V; Thu, 09 Oct 2025 02:37:51 -0400 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=dOwcENpnuhDuSiuI6uTi/Rp+lB9CrZrL3lrK5taNhvU=; b=hr9bCD2eXOgCflP3mEf5 wFoshsgOiv0MUiFAjl7SBfeA2bKk8TSy2bAX6GTgEfOKnCsU3YjU1cN6HA7XjSM0mBnAKQ7A/+PN8 MPyWp86n5MbRsNm52V4lPKpfRXs0KVIWcKArdjJwGp0Ihvtr1jllh3zxY6k2f2y7TPKUDXPNxcT8H Swgu19rKCw85P6EiqLVrOvUKbgr5Ur4E/k7Tn1K1iiU+TsVGUo4mwoKgqLkBMceoJgjfuCkbMQ1CD okGc3uHF2UCg7SIsYkixFFFvMm3qRG3DDtN9KNkTttwz2tdzkwNkxa4WRE/+nnTFq483lYyhw3HnF cnmqihHqxAcO3g==; Date: Thu, 09 Oct 2025 09:37:45 +0300 Message-Id: <86qzvca8cm.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?iso-8859-1?Q?M=F6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2cy6xkx7s.fsf@HIDDEN> (message from Gerd =?iso-8859-1?Q?M=F6llmann?= on Wed, 08 Oct 2025 21:30:31 +0200) Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm References: <874iscb5i8.fsf_-_@HIDDEN> <86jz17cku0.fsf@HIDDEN> <87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN> <87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN> <86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN> <87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN> <m2cy6xkx7s.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79584 Cc: oliver.reiter@HIDDEN, pipcet@HIDDEN, eller.helmut@HIDDEN, 79584 <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: Helmut Eller <eller.helmut@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, > oliver.reiter@HIDDEN, 79584 <at> debbugs.gnu.org > Date: Wed, 08 Oct 2025 21:30:31 +0200 > > Pip Cet <pipcet@HIDDEN> writes: > > > Pip Cet <pipcet@HIDDEN> writes: > > > >> I suggested the hash table index, but same idea. > > > > This seems to work, at least. No need to recompile the module, either. > > Nice! And i can confirm it's compatible using the vterm module I used > before the patch. Thanks, I think compatibility with Emacs using the traditional GC is very important.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 19:30:55 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 15:30:55 2025 Received: from localhost ([127.0.0.1]:34427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6ZsB-0005UA-P2 for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 15:30:53 -0400 Received: from mail-ej1-x632.google.com ([2a00:1450:4864:20::632]:45442) 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 1v6Zs0-0005RC-Io for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 15:30:45 -0400 Received: by mail-ej1-x632.google.com with SMTP id a640c23a62f3a-b3da3b34950so25852866b.3 for <79584 <at> debbugs.gnu.org>; Wed, 08 Oct 2025 12:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759951833; x=1760556633; 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=Om5x1PugZe9aw/UaeQRnCUQD/zr0h+khJvQ52CAxxC4=; b=EOkBGasTYpmW+2tKXWIpFWFIe3cFBg/fsjUIuqozPiKqkcQSSPtvIjuPQLgapfz9nK +o/7722QV0O7KqD+NWRCaqqCUjY4c23iheWeaGjVXiJR5qw/94gxORZs4FJo002qKcYD 5e0FJL92j7TVJcpoE09irMCkBTakijt9BjAt3M9Ys04QG455EpNqsevhCjlYxooqpqTe SPK4RfhmSLKo4rf+Hp8DUEZ8cwrIgCF3KJAwRX11pgIj1pPt8fpg6ommktj4OCllJ3M3 LAtSoYfkHNIcjYBm3CYFwUQ13cPP+XlaFJkWRLHIpc1eanCajo+hWVxmZwbz+nrWoTtK gVSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759951833; x=1760556633; 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=Om5x1PugZe9aw/UaeQRnCUQD/zr0h+khJvQ52CAxxC4=; b=vzUZ5j2u3XYcLZifSIBwE5d+TtM6trvpWO3wJrs+sKYmHtFaxno+1KnVXdEBF+gG8R PIu+EeqBkXVa6bjLsj47cAHiqpIRBAd2g/Kd3+K6pOB4Kim8PCifA+GOP7w3P5kOTktc iIuaFDRWSeXJV1nBpTsCaBXcppLru0odGcSAbhgfx1ohh/ppwcFs5qMECUX22gZhz9h6 6BB6eUw7JNC4KwQkjbdjy3ZT8EMVQ2VP3aWggYll6u9uun+bWcebt69R+4hs4TeouWjn chHV9r6/zOVlc5ujGXl+dqZlBfON02DV9CsF4ZE3DLza8wFA59P2bSByzNO9/ByylB6j ClQQ== X-Forwarded-Encrypted: i=1; AJvYcCWIctCnp0Dt18w79P4GYjPf+c1rODf9W4rjsYUw6jFj7QyHPpqOThjRSFCUUGHqb1jEFmk25w==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz9YYrUfhVaUnpFnCrd/N7Ksr/9EglaoLPvEdCm3uJWOxrH3x9s hIhs9C+tR4z+z7gPh+9uuBw+Ha5YfYXsxFq9sIDRCCzCkxKsrIvEVxoE5IZxgw== X-Gm-Gg: ASbGncugll3nyB0dzi6zuTZjPVHtMbHMmzcXf03KyCUZQJ50yS+OU9RHniWIc4oBWRB 5sqbtejXh75WOJROdrn5VR42XYcU4BRykiWsOHuZ9A3GU56DrZbThGADEbhQe25bT5ZUeWsRPjb tBCrU4wPe7hdbtyWbaY0Vvcz8CIl+43EBFhRj6ueGW24VTkW/rwgf7dGscEh1wdWg89tZeCzv8i BY50Kexmc7zKhdwJQWt3ikGCwgHybVf8/73WCg4ZrESEpmXVnkLbhyffIYlqxkqZWzK/YFYYdni xkerXgA7p/KFA0LQtynCctgLX9klCksOEMk3Zmis5ZDRqsW7hbqzf1rNZFBP6FHrsjfv7Fg3rfC +PYngKWFQajf3bM3H7CU9XgcoWs6T4PesqGv24rPhgGbDZIJwSBOfsqIyPcD9PwKQM96nZc+Vnl PSUKlYVRy+FnQLx91PMwaf+fVCQoYc7Q0fMG2ImfYFaEhrBCMhJyVvN9M= X-Google-Smtp-Source: AGHT+IHPMd1JZVkcIw+yGdb8VWVMnxQkHX+hULu3/oWEl3J3or05szfbW0u6r4riqaSWrR4Txq8OGg== X-Received: by 2002:a17:907:86aa:b0:b40:9dbe:5b57 with SMTP id a640c23a62f3a-b50ac6cf7ecmr530469666b.62.1759951832926; Wed, 08 Oct 2025 12:30:32 -0700 (PDT) Received: from pro4 (p200300e0b7062100a4dba41779cb9384.dip0.t-ipconnect.de. [2003:e0:b706:2100:a4db:a417:79cb:9384]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b53bd62addbsm147779966b.4.2025.10.08.12.30.32 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Oct 2025 12:30:32 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <87o6qhcjzy.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <86jz17cku0.fsf@HIDDEN> <87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN> <87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN> <86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN> <87o6qhz6wl.fsf@HIDDEN> <87o6qhcjzy.fsf@HIDDEN> Date: Wed, 08 Oct 2025 21:30:31 +0200 Message-ID: <m2cy6xkx7s.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: 79584 Cc: oliver.reiter@HIDDEN, Eli Zaretskii <eliz@HIDDEN>, Helmut Eller <eller.helmut@HIDDEN>, 79584 <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: > Pip Cet <pipcet@HIDDEN> writes: > >> I suggested the hash table index, but same idea. > > This seems to work, at least. No need to recompile the module, either. Nice! And i can confirm it's compatible using the vterm module I used before the patch.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 19:04:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 15:04:40 2025 Received: from localhost ([127.0.0.1]:34298 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6ZSp-000383-IO for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 15:04:39 -0400 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]:51346) 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 1v6ZSj-00037i-3r for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 15:04:34 -0400 Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-637dbabdb32so260208a12.2 for <79584 <at> debbugs.gnu.org>; Wed, 08 Oct 2025 12:04:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759950266; x=1760555066; 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=Uab5jtQx/fBDbatrRAPG04qEioLt2ausijWZbTCtAok=; b=lqd+qZyXtJRJ72ZkpbmQ0iPi8fKAFRphMPzGq/+adJD41bPk9MtQJmuLxKmwCqxcgN stRCDFOtRx5rCWrOKwKO5MvG9UdOYxD/inhP0cCnrNL62sieEb55DnNCTo4jdFnply/h vNp0bk0OZRxQw3tVlZBMa8C7JzAMZIkwSSjLLRkCSEqZ9KiDuUZt0BIBrRFHDyt6jzst LCtfbQaymJLJ2Q/zq4l5xEA1DKj6O8nbVMZyP1xsRIq6mEltYBu2RSwXB/TZTFkhySXd 8sVSeyEk2luDlJmCjqovv+Zr7f3x9Yh/1lLovnxaS9BQrRKTem/eSeB6dcWxD/Yso5ua BgqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759950266; x=1760555066; 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=Uab5jtQx/fBDbatrRAPG04qEioLt2ausijWZbTCtAok=; b=khdSrzUH9D/wRaUxfD0hUdQY+qVhbEg1XNDjyxNxL1088rcLkwRVeaT4NAq2WLkUnq gal9gYETgd7aSMSSAxodu6gYjnC2tE+kZ0KdWIKp4eb+Eh9C8+J/W6lMhpjHPnBSlbpP Zszbx+n5eaVjJNtBWpEkzAiBf0+RNJBd4NXPB1WHiosdS1lrJNcU4FDrKp+wlpliSIyQ 6yNWRsSRsHhzKglG1hgAYGzwGRR/mrUO9tFz3Er0WESoLztJvk17DqLTs8vnWtdAsYiw iJSDkZ/tXYIa9YHSB/uMCRiXyzGwf1W3QSZAp7Z5rcIKfgDTYpyUlMGt/+3qDCOex766 uFtg== X-Forwarded-Encrypted: i=1; AJvYcCWtFN1s1wRufj9PS4QWqzGd0g9Wq6Z2q6EW/GLIJJLb//fYecrto8FgDvj7wMcrWdT8TepStw==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yy4iZhlf15yOC4HbaCN1YdYGJx14AEtCqobL/YaESDCIevHALjy HVQFJS/p99mvnMbdz5Ti5v//VNFG3q7FfGYuhdebAd+vA9+UuefL1AmjEzHQoQ== X-Gm-Gg: ASbGnctyCpDySQ8AgSLS7NNbA6VjYKFyyDfY0EcWxKBAnDjwy9NWqMaAXk1kEurohyF ykGeNPU0fzlUb0qIgpNM4SYqevfEXA2qmJ2wHC7DvxdzAJOSoIWaFkGA4rMFsOG4WKZCh1aocya I+Mskul4N27rfhpWqIWU+xlqTytWbLgJxo0IRbpzUkzC4qkerrr1SMpSvNFlLYHIhwuH2whVrPI qA8alYexJliQSwK9LtWNO2tJM3bWX5SP5i8XSd7M10cOo2echiNEpoeW3TA5yDtgUPA+sUwR0pL Z9LRcPcwUrorY3dYV7uVoES/esKxXLVUM2NOuJZcD4rhsKTpSbvQRKYOEykmejpLqwtxAjnQFi6 tD2JPoZB+kT0jZAeeLcPui0654P39g1MwlTavwVNOC0vRXKtIVBcsg7M5YrdNnCy4+Vm3IymsGd M1RO7+RYxKmHjnYMDhuICpRU7s/di3sbTXFotC8pc5IHPPQRT4KQG1/u0= X-Google-Smtp-Source: AGHT+IGltm7WEeNMCnXe/kCxxaN3CocG0shEdLosniYy5hv5qgp3rzJGfCp2Um5ZphZSU94kZHAZ1g== X-Received: by 2002:a05:6402:438a:b0:639:f413:846a with SMTP id 4fb4d7f45d1cf-639f413869cmr1101357a12.9.1759950265649; Wed, 08 Oct 2025 12:04:25 -0700 (PDT) Received: from pro4 (p200300e0b7062100a4dba41779cb9384.dip0.t-ipconnect.de. [2003:e0:b706:2100:a4db:a417:79cb:9384]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-639f3d0a0e0sm559423a12.32.2025.10.08.12.04.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Oct 2025 12:04:25 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <86y0pl9tgl.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN> <87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN> <87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN> <87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN> <86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN> <87o6qhz6wl.fsf@HIDDEN> <m2v7kpnw1n.fsf@HIDDEN> <86y0pl9tgl.fsf@HIDDEN> Date: Wed, 08 Oct 2025 21:04:24 +0200 Message-ID: <m2jz15nrk7.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: 79584 Cc: oliver.reiter@HIDDEN, pipcet@HIDDEN, eller.helmut@HIDDEN, 79584 <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>, pipcet@HIDDEN, >> oliver.reiter@HIDDEN, 79584 <at> debbugs.gnu.org >> Date: Wed, 08 Oct 2025 19:27:32 +0200 >>=20 >> Helmut Eller <eller.helmut@HIDDEN> writes: >>=20 >> > Do we need to preserve some form of binary compatibly?=20=20 >>=20 >> I'm not sure how that works. There is emacs-module.h.in which is patched >> with the emacs major version. Maybe that prevents loading old binaries >> that don't fit to the Emacs version being used. > > No, we only update the struct if new fields are added. Otherwise the > version tag is just for documentation. Good to know, thanks.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 19:04:11 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 15:04:10 2025
Received: from localhost ([127.0.0.1]:34295 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6ZSL-00037I-Vz
for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 15:04:10 -0400
Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:42022)
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 1v6ZS7-00036a-Aa
for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 15:04:03 -0400
Received: by mail-wr1-x42b.google.com with SMTP id
ffacd0b85a97d-3ee15505cdeso229932f8f.0
for <79584 <at> debbugs.gnu.org>; Wed, 08 Oct 2025 12:03:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1759950228; x=1760555028; 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=ncfUhFq1Fualo4TxlZNhd5QHxLSiDzncLyKjuLj/HrA=;
b=fstS1/3vp/N9c6UrrAMI+FE8VRsK0Qs2/gxTQ90+WVowayLJD444Yrdys/85hyzRWV
FgVvcOAExPrsxA3zBkFo60elaUYTXUZqWKI0TiEOsh3LkG10yP4mC8QfIrDXfcKigm0p
ZTU7YfejtUB79lRRe/vXvmzAqp//FRsvj4esi3axI0ghx6RoRDumoNPjcjLr33QYmxU3
BEhaL7oeXBm+aVo+PUp7b8pniH+0T+2xljRsOsuCpMo9pM/8ptR/KgBjh6vOCpkIDXqU
ieDA6p7iMUFoNvMJKTVFTrtUeDW0FMaO4Ym7tSHQt2LoX9wpDrdSXxy+COetV8wWMYKC
2Ivg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1759950228; x=1760555028;
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=ncfUhFq1Fualo4TxlZNhd5QHxLSiDzncLyKjuLj/HrA=;
b=Qg2MscxyGhpqR9g13ut0wpkybUFwT9MHXLGL5NkRbbCKLZSzp9ErJBOltpY3C+NMfX
ZtF5CB/uXS9F8fLA/MuLGf9/ZJlqzShrFdQG81mBrDm6V7p5F1bpuGdx9NIaMvLb86Ee
oSF6TyVRHH7v5MyONzLBpIOio6vYar9np3fa2AJCKezbH3raTqeCpkfKLYfUJ72nACS7
lv0Wo7U2802akKEuFpIa5WEw1G/QRwqHQCTWAnPHlPXHSc/Q0FLCYR66jqO0AwS3Lj1q
ZE9/5uz3qFzyAMfMVjDX4mJhKt79dBeM9p94yiyS0v/Vm0f9toTTB8vaUyhssOyaWCbb
0+uQ==
X-Forwarded-Encrypted: i=1;
AJvYcCUB76L1JNye0PQ9wY1KuwC4yPflFDYSwGXpwMhEVJKNz+1UVl8BTPgtps6Yj1o5og1kODSglw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxmPtVsbVcjv2nGf230pUhEN765AKGHo7KGzk6kEYVBeq5UuGpQ
DY4By0X7K9JhYxuhLYNTw0NiZj01uCeEDgXmV3+MZJ2G4aXQeL14LICi
X-Gm-Gg: ASbGncszc0MDIYYu90doASvYx4Mf1F356bVxfy93KM9w1Y1UEjIunol4Zj3rkp3Xbkk
BGenaBkSDUAdZaMSxxfCq8Y1D5Q8oSlu7E9TbB6UH2w5tggt/14qcyvDBYD31MqG4kOAU8fiQhU
KvG895tRKdrVpbLyC17c4EfzKd73G0QxeZfnDTyO0hQAT7vQXQDpCJ58CgA91z+aOBNu8y0VRse
i/oW0AgpfGdFGnJfo4hKwz9AqVbSKo+jcAl4WjmTRZoxb4TQ3OMGN2azSU2H7DHcbL5ruAIIFi+
Z7+6X++SI33FAYw6zJYSU2F7EZsNiJM2rr798OmC9usPY1uuKBV578VPRwsdqCZgogzTSlMK6eC
oaNPa42Czcwd4946ogadhQls3KnhB3AgOwyCDxGQhavFQo0ZPS293SxqmfNfJP78sWp/8SEpOZ9
qvppRPxTVLL6TJWfwvCRMwnkUmvaD5qmpJyWnaZXrRpQuDMX0Hfm+YXzA=
X-Google-Smtp-Source: AGHT+IE5X1mEJ7JAqrnz6H30uuHA04OGW8HZ8tsPM/Kg/Zt9lFPV0FdF637cUP3yZHq2sXHQL0ZuMA==
X-Received: by 2002:a05:6000:1447:b0:407:d776:4434 with SMTP id
ffacd0b85a97d-42582a05718mr6195144f8f.30.1759950227947;
Wed, 08 Oct 2025 12:03:47 -0700 (PDT)
Received: from pro4 (p200300e0b7062100a4dba41779cb9384.dip0.t-ipconnect.de.
[2003:e0:b706:2100:a4db:a417:79cb:9384])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-46fab3d92c0sm19599305e9.3.2025.10.08.12.03.47
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 08 Oct 2025 12:03:47 -0700 (PDT)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <87zfa1ctwm.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN>
<87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN>
<87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN>
<86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
<87zfa1ctwm.fsf@HIDDEN>
Date: Wed, 08 Oct 2025 21:03:46 +0200
Message-ID: <m2o6qhnrl9.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: 79584
Cc: eller.helmut@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
oliver.reiter@HIDDEN, 79584 <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:
>
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>
>>>> From: Gerd M=C3=B6llmann <gerd.moellmann@HIDDEN>
[...]
>> In any case, I would propose to get rid of the AMS pool. I don't see how
>> AMS could possibly work in conjunction with other pools. IMNSHO, the
>> reference should never have mentioned it because it is simply broken.
>> That's no "don't use in production". Grr.
>
> I wouldn't go quite that far; AMS was probably very useful at some
> point, but optimizing compilers make it hard to avoid ambiguous interior
> pointers which keep objects alive, and while it probably wouldn't be
> hard to fix AMS to support those, it hasn't been done yet.
>
> But that's not the problem here: the problem here is that if you follow
> a pointer into an AMS segment, that pointer must be somewhere MPS knows
> about. So they're just like AMC pointers in that regard, which means
> they're unsuitable for global references that are stored outside of
> MPS-managed memory.
That's what I meant by "grr", and I'll put the interior pointer stuff on
top:-). AMS does not play nice from my POV.
>> What could replace it? Let me pull an idea out of thin air, for
>> discussion:
>>
>> Replace igc's AMS pool with a new AMC pool, let's call that pool IP,
>> that is used to create immovable objects like global_refs. Global_refs
>> may not move because, if they did, the global emacs_values in modules
>> would have to change, and we don't have access to these, we don't even
>> know if they exist.
>
> But they also don't have to be pointers! Making an emacs_value store a
> hash index (either directly or by returning a pointer to one)=20
(Caveat: hash_table_resize or what the name is.)
> would mean we wouldn't have to do any GC tricks at all for global
> refs. For local environment emacs_values, we'd probably still want to
> store a pointer.
>
> My first approach was to make use of the unused tag to create a
> Lisp_Object type that represents a hash index in the global refs hash.
> emacs_value would be a pointer to a Lisp_Object, but if it has tag 1
> value_to_lisp would untag it to retrieve the hash index and return the
> hash element rather than the original Lisp_Object. The other tags are
> stored in the environment and can be retrieved directly.
So we we have, in the end, a Lisp_Object pointing to a global_ref in
AMS. That reference is containing in an AMC hash-table object, right?
The global_ref reference in the hash-table is scanned by MPS. So far so
good.
Could you please explain how the Lisp_Object X contained in the
global_ref is updated/fixed when X is moved?
>
>> We make objects in IP immovable by creating ambiguous references to
>> objects in IP when they are created. For simplicity, assume we have an
>> array of pointers to=C2=B4objects in IP that is registered as ambiguous =
root.
>> Adding an object to that array could be O(1) by having a free-list (like
>> marker_vector) and so on. Removing an object could be O(1) by keeping
>> the index where it is stored in the global_ref object. Or the array
>> could be
>>
>> struxt immovable_references {
>> struct entry {
>> void* reference;
>> struct entry* prev_free;
>> struct entry* next_free;
>> };
>> struct entry* free_entries;
>> size_t capacity;
>> struct entry entries[];
>> };
>>
>> (Only for the idea, don't look at it too closely.)
>
> So the entire struct would be an ambiguous root, and we'd perform our
> own management of it using a built-in free list rather than letting MPS
> do it?=20
Maybe simpler to understand is to imagine this being like a
marker_vector, only differently. Slots serve as ambiguous references to
global_refs so that these are pinned. A free-list makes it possible to
find free slots and so on.
> That seems complicated, and it still means every global reference
> would slow down the start of every GC cycle, which is extra
> user-visible latency. At least in theory, the hash index approach
> doesn't do that.
True, but on the other hand, I guess there aren't many global_refs, so
the array could be small. And avoiding to refer to AMS objects except
from MPS memory (if it works, I haven't understood it yet) seems like a
pretty trick, too :-).
>
>> Since global_refs must use a make_ref/free_ref pattern I think that
>> should work. And I think it would have relatively low overhead.
>>
>> Using a second AMC pool would be for avoiding some pinned objects among
>> the "normal" ones. Maybe one could even do without, and use the normal
>> AMC pool, don't know. Maybe one should even try that first.
>
> IIUC, pinned objects in AMC pools prevent the entire segment from ever
> being freed, and there is no mechanism for reusing it, either, so that's
> a permanent waste of memory.
Are you saying that if a segment has ever contained a pinned object it
is lost forever, and will not be reused when the last pinned object
disappears?
> AMC pools aren't really designed for permanently-pinned objects. It's
> tempting to ignore that and allow objects to be pinned intrinsically,
> without the need for an ambiguous reference to do so, but we'd have to
> be very careful to avoid wasted memory.
That's why I thought of using a second pool in the hope that would
alleviate the problem.
>
>> WDYT?
>
> I think my preference would be the tagging scheme to make emacs_value
> either an encoded hash index or a pointer to a Lisp_Object (as before).
>
Fine with me. I don't feel strong about one or the other.=20
Another related thing: I see we also use AMS for threads. Can we expect
similar problems as with global_refs with threads?
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 18:45:19 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 14:45:18 2025
Received: from localhost ([127.0.0.1]:34280 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6ZA6-0002Lf-4A
for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 14:45:18 -0400
Received: from mail-4316.protonmail.ch ([185.70.43.16]:55843)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1v6Z9z-0002H9-F4
for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 14:45:12 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1759949103; x=1760208303;
bh=U6WenQRqcV4R+TPIMeZj4jnblXpuwEtV5O4tLU6PYJI=;
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;
b=fOAcP6f4uwxz54bPUNSP3z7MX8yZwzYcdp2zBATxrsamh3FtvshydEVLl9PCUblZC
MZfaFCdBH40jz+shYornZ3zsT/ej4FGab4JK2uxeIXdCYx0ZloGNJdGvcquEcn9AwG
DYTLod0jWz2P5xVqFygM/30OPqGZgfb1KG09v8aD0LWetg5h9pJuXnrEEe89hDx9Cm
aLhe/klToFUJ0PSAcMByVvHG+55JFWObPhZO5BxBiFx0hEpMH4hU0t3VjktPXKf8tb
/uzPCrI1grjll/toTVbRJUR3SPZjycECNWnakjKoHkyC+RW+e3M0ZKn9emVUoR5Drd
WvYA65rSAGJQA==
Date: Wed, 08 Oct 2025 18:45:00 +0000
To: Helmut Eller <eller.helmut@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
Message-ID: <87o6qhcjzy.fsf@HIDDEN>
In-Reply-To: <87o6qhz6wl.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86jz17cku0.fsf@HIDDEN>
<87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN>
<86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
<87o6qhz6wl.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 64dccab3021cb6042c7ee909da276d63839455ec
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: 79584
Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>,
Eli Zaretskii <eliz@HIDDEN>, oliver.reiter@HIDDEN,
79584 <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:
> I suggested the hash table index, but same idea.
This seems to work, at least. No need to recompile the module, either.
From 8a349644e6df0ac9349f2d7ff860933bd73ec7b6 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Wed, 8 Oct 2025 18:17:06 +0000
Subject: [PATCH] Fix module global references for MPS (bug#79584)
* src/emacs-module.c (module_global_reference_p): Return false for
local references.
(module_make_global_ref): Store the hash index, not the Lisp value.
(module_free_global_ref) [MPS]: Free the reference.
(value_to_lisp): Handle new global references.
* src/igc.c (fix_global_ref): Assert we're looking at a global
reference, don't do anything else.
(igc_alloc_global_ref): Use 'xzalloc'.
(igc_free_global_ref): New function.
* src/lisp.h (struct emacs_value_tag): Enlarge to distinguish global
values (hash table index) from local values (Lisp_Object).
---
src/emacs-module.c | 39 +++++++++++++++++++++++++++------------
src/igc.c | 14 ++++++++++----
src/igc.h | 5 ++++-
src/lisp.h | 10 +++++++++-
4 files changed, 50 insertions(+), 18 deletions(-)
diff --git a/src/emacs-module.c b/src/emacs-module.c
index f3a92500f62..fcb81143c7f 100644
--- a/src/emacs-module.c
+++ b/src/emacs-module.c
@@ -393,6 +393,9 @@ XMODULE_GLOBAL_REFERENCE (Lisp_Object o)
static bool
module_global_reference_p (emacs_value v, ptrdiff_t *n)
{
+ if (!v->is_global)
+ return false;
+
struct Lisp_Hash_Table *h =3D XHASH_TABLE (Vmodule_refs_hash);
/* Note that we can't use `hash_find' because V might be a local
reference that's identical to some global reference. */
@@ -436,11 +439,11 @@ module_make_global_ref (emacs_env *env, emacs_value v=
alue)
=3D ALLOCATE_PLAIN_PSEUDOVECTOR (struct module_global_reference,
PVEC_MODULE_GLOBAL_REFERENCE);
#endif
- ref->value.v =3D new_obj;
+ Lisp_Object lisp_value;
+ XSETPSEUDOVECTOR (lisp_value, ref, PVEC_MODULE_GLOBAL_REFERENCE);
+ ref->value.is_global =3D true;
+ ref->value.u.hash_table_index =3D hash_put (h, new_obj, lisp_value, =
hashcode);
ref->refcount =3D 1;
- Lisp_Object value;
- XSETPSEUDOVECTOR (value, ref, PVEC_MODULE_GLOBAL_REFERENCE);
- hash_put (h, new_obj, value, hashcode);
MODULE_INTERNAL_CLEANUP ();
return &ref->value;
}
@@ -471,7 +474,12 @@ module_free_global_ref (emacs_env *env, emacs_value gl=
obal_value)
struct module_global_reference *ref =3D XMODULE_GLOBAL_REFERENCE (va=
lue);
eassert (0 < ref->refcount);
if (--ref->refcount =3D=3D 0)
- hash_remove_from_table (h, obj);
+=09{
+=09 hash_remove_from_table (h, obj);
+#ifdef HAVE_MPS
+=09 igc_free_global_ref (ref);
+#endif
+=09}
}
=20
MODULE_INTERNAL_CLEANUP ();
@@ -1451,8 +1459,14 @@ value_to_lisp (emacs_value v)
=09=09 "of %"pD"d environments"),
num_values, num_environments);
}
-
- ok: return v->v;
+ ok:
+ if (v->is_global)
+ {
+ struct Lisp_Hash_Table *h =3D XHASH_TABLE (Vmodule_refs_hash);
+ return HASH_KEY (h, v->u.hash_table_index);
+ }
+ else
+ return v->u.local_value;
}
=20
/* Convert an internal object to an `emacs_value'. Allocate storage
@@ -1528,7 +1542,8 @@ allocate_emacs_value (emacs_env *env, Lisp_Object obj=
)
storage->current =3D storage->current->next;
}
emacs_value value =3D storage->current->objects + storage->current->offs=
et;
- value->v =3D obj;
+ value->is_global =3D false;
+ value->u.local_value =3D obj;
++storage->current->offset;
return value;
}
@@ -1727,11 +1742,11 @@ syms_of_module (void)
Fput (Qmodule_out_of_memory, Qerror_message,
=09build_unibyte_string ("Module out of memory"));
=20
- staticpro (&module_out_of_memory_symbol.v);
- module_out_of_memory_symbol.v =3D Qmodule_out_of_memory;
+ staticpro (&module_out_of_memory_symbol.u.local_value);
+ module_out_of_memory_symbol.u.local_value =3D Qmodule_out_of_memory;
=20
- staticpro (&module_out_of_memory_data.v);
- module_out_of_memory_data.v =3D Qnil;
+ staticpro (&module_out_of_memory_data.u.local_value);
+ module_out_of_memory_data.u.local_value =3D Qnil;
=20
DEFSYM (Qmodule_load_failed, "module-load-failed");
Fput (Qmodule_load_failed, Qerror_conditions,
diff --git a/src/igc.c b/src/igc.c
index 35e0ec3c596..d30652c5356 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -2723,7 +2723,7 @@ fix_global_ref (mps_ss_t ss, struct module_global_ref=
erence *r)
MPS_SCAN_BEGIN (ss)
{
IGC_FIX_CALL_FN (ss, struct Lisp_Vector, r, fix_vectorlike);
- IGC_FIX12_OBJ (ss, &r->value.v);
+ eassert (r->value.is_global);
}
MPS_SCAN_END (ss);
return MPS_RES_OK;
@@ -4302,15 +4302,21 @@ alloc_immovable (size_t size, enum igc_obj_type typ=
e)
}
=20
#ifdef HAVE_MODULES
-void *
+struct module_global_reference *
igc_alloc_global_ref (void)
{
size_t nwords_mem =3D VECSIZE (struct module_global_reference);
- struct Lisp_Vector *v
- =3D alloc_immovable (header_size + nwords_mem * word_size, IGC_OBJ_VEC=
TOR);
+ struct module_global_reference *v
+ =3D xzalloc (sizeof *v);
XSETPVECTYPESIZE (v, PVEC_MODULE_GLOBAL_REFERENCE, 0, nwords_mem);
return v;
}
+
+void
+igc_free_global_ref (struct module_global_reference *ref)
+{
+ xfree (ref);
+}
#endif
=20
Lisp_Object
diff --git a/src/igc.h b/src/igc.h
index 13b5646f387..1aaf1f60909 100644
--- a/src/igc.h
+++ b/src/igc.h
@@ -80,7 +80,10 @@ #define EMACS_IGC_H
void igc_remove_all_markers (struct buffer *b);
void igc_resurrect_markers (struct buffer *b);
Lisp_Object igc_alloc_symbol (void);
-void *igc_alloc_global_ref (void);
+#ifdef HAVE_MODULES
+struct module_global_reference *igc_alloc_global_ref (void);
+void igc_free_global_ref (struct module_global_reference *);
+#endif
=20
struct Lisp_Buffer_Local_Value *igc_alloc_blv (void);
void *igc_alloc_handler (void);
diff --git a/src/lisp.h b/src/lisp.h
index 391c5bef6e9..3c8500c2237 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -6345,7 +6345,15 @@ maybe_gc (void)
=20
/* An `emacs_value' is just a pointer to a structure holding an
internal Lisp object. */
-struct emacs_value_tag { Lisp_Object v; };
+struct emacs_value_tag
+{
+ bool is_global;
+ union
+ {
+ Lisp_Object local_value;
+ EMACS_INT hash_table_index;
+ } u;
+};
=20
/* Pseudovector type for global references. The pseudovector tag is
PVEC_OTHER since these values are never printed and don't need to
--=20
2.50.0
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 17:48:42 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 13:48:41 2025
Received: from localhost ([127.0.0.1]:34139 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6YHJ-0006wx-6E
for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 13:48:41 -0400
Received: from mail-24418.protonmail.ch ([109.224.244.18]:44917)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1v6YHE-0006wS-8G
for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 13:48:37 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1759945709; x=1760204909;
bh=p1k+qCns9Im2ULD/gS5S75p3EkDPhMBRzqRa86Mw45A=;
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;
b=OYCYOE1PHcmhXL/pJ+roda5Xnu3FM4cJQGY9IWLYhyXGaZIWS0Eoa5dm1dqLAUmzE
mFibMM9w5pbu48py0L2m3hu//8AMQBcULF77LfuKdQpnjBKZuemp1JUujxt2HPfmDX
hvbx9+pphE5weEr1QdIhMwrouzRyW+is4QY+QghKkZ2tN2Vd4z9E2tftUFjisdvKJP
M8zaTczpRqH/0kvq1p1mGK99EQ0nnvCghCeDJH3woT6quLvHKN9kHkIMSIGkYiy5hM
NqcooKGgANcwcePKGus3rudYi/q6BkFJLYxJLkypihGgkeR85qzxRvScRu1LAG/KHy
JLdZ0ijGFmm7A==
Date: Wed, 08 Oct 2025 17:48:23 +0000
To: Helmut Eller <eller.helmut@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
Message-ID: <87tt09cmmd.fsf@HIDDEN>
In-Reply-To: <87o6qhz6wl.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86jz17cku0.fsf@HIDDEN>
<87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN>
<86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
<87o6qhz6wl.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 46894ffa9472f125555756d62c52c1659a179cf5
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: 79584
Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>,
Eli Zaretskii <eliz@HIDDEN>, oliver.reiter@HIDDEN,
79584 <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 (-)
"Helmut Eller" <eller.helmut@HIDDEN> writes:
> On Wed, Oct 08 2025, Gerd M=C3=B6llmann wrote:
>
> [...]
>>>> I guess the first question is if global emacs_values are a thing that =
is
>>>> supported or not.
>>>
>>> AFAIU, they are supported, provided that the module adheres to the
>>> protocol of their support: see "Module Values" in the ELisp reference
>>> manual, where it describes make_global_ref and free_global_ref, and
>>> user pointers as an alternative.
>>
>> Yeah, that reads like it is supported, unfortunately :-/. (I find it a
>> bit unsafe to return global_refs as emacs_value interior pointers, and
>> store them as global variables, because _only_ global_refs allow that,
>> but be that as it may. It is what it is.)
>
> Do we need to preserve some form of binary compatibly? If we could
> change the size of emacs_value, then we could use something like:
>
> struct emacs_value {
I'm not sure whether you mean "struct emacs_value_tag" here (which would
make sense but be a little wasteful) or whether you want the emacs_value
type to be a struct (that would break binary compatibility, and
generally seems like a bad idea to me).
> enum gc_handle_type {LOCAL, GLOBAL} type;
> union {
> struct local_gc_handle local;
> struct global_gc_handle global;
> } gc_handle;
> };
That's a lot of zero words on the stack that get scanned ambiguously
(the current value_frame_size is 512, so unless we change that we'd
waste 4 KiB of space just to store the handle types for a minimal
environment).
> struct local_gc_handle {
> Lisp_Object obj;
> };
>
> struct global_gc_handle {
> size_t key;
> };
>
> Local GC handles are only safe as long as they are on the stack and
> rely on the usual conservative stack scanning. This would avoid the
> emacs_value_storage and associated jmpbuf gymnastics.
Currently, local GC handles sometimes live in additional storage which
isn't on the stack; still safe because it's an ambiguous root.
However, it's important to be precise here: it's the struct
emacs_value_tag which usually resides on the stack (or, otherwise, in an
ambiguous root). The emacs_value which points to it doesn't have to be
on the stack, but it doesn't outlive its environment no matter where you
store it.
> Global GC handles use the integer as key in a hashtable (or similar) to
> look up the actual Lisp_Object (or module_global_reference if need the
> reference counting stuff).
I suggested the hash table index, but same idea.
Pip
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 17:47:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 13:47:24 2025 Received: from localhost ([127.0.0.1]:34134 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6YG3-0006t5-Q4 for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 13:47:24 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:58814) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1v6YFz-0006sf-C0 for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 13:47:20 -0400 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 1v6YFp-0005TZ-PL; Wed, 08 Oct 2025 13:47:10 -0400 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=1xJxQ7a7drWVkcVKDRdWK/U1EDCRIva2vB6aZ8k/mHw=; b=eEDNZPScmET/vjsozJDn tAKsm2kwCNgpYa157ZBruaWEJ47GiZWmebwaEvP9LETzXg68enuo/xFuO6x/r+Aw1XAweofvccYsV EMpsf1ozYYvreP6tX4BPqG1kUn9zedOQgzpzkp8Ey1uuREcS2kd9z5G+htNMJ7jQYO3VHbqwT8zB4 grkZMvnKM97p1v8CKaJB7R9RR723yYHbOAaIzivGCW3d2DaC3LGr4PAKQNXXGsUlSlO5/vNyNt8bo Cet9jXH3Bg0FXof7xUJhvjjxtb97gVa3Nzv8Op1+D2izg8/tB+I88qB4AiqqZBKkHitH7w5LXscHf bIbv6iZuNsWzeA==; Date: Wed, 08 Oct 2025 20:47:06 +0300 Message-Id: <86y0pl9tgl.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m2v7kpnw1n.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Wed, 08 Oct 2025 19:27:32 +0200) Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN> <87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN> <87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN> <87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN> <86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN> <87o6qhz6wl.fsf@HIDDEN> <m2v7kpnw1n.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: 79584 Cc: oliver.reiter@HIDDEN, pipcet@HIDDEN, eller.helmut@HIDDEN, 79584 <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>, pipcet@HIDDEN, > oliver.reiter@HIDDEN, 79584 <at> debbugs.gnu.org > Date: Wed, 08 Oct 2025 19:27:32 +0200 > > Helmut Eller <eller.helmut@HIDDEN> writes: > > > Do we need to preserve some form of binary compatibly? > > I'm not sure how that works. There is emacs-module.h.in which is patched > with the emacs major version. Maybe that prevents loading old binaries > that don't fit to the Emacs version being used. No, we only update the struct if new fields are added. Otherwise the version tag is just for documentation.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 17:27:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 13:27:51 2025
Received: from localhost ([127.0.0.1]:34089 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6Xx8-0005Yo-HH
for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 13:27:51 -0400
Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:53435)
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 1v6Xwz-0005Xl-QA
for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 13:27:46 -0400
Received: by mail-wm1-x334.google.com with SMTP id
5b1f17b1804b1-46e33b260b9so1010105e9.2
for <79584 <at> debbugs.gnu.org>; Wed, 08 Oct 2025 10:27:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1759944454; x=1760549254; 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=LChHRkxlgsW5tEOfo4zYomfUmA567rAD6/YemagFv7k=;
b=BYY6veM3eQi8UshnTJ5Z9gSeqAks7WWWAdXuZZvVyGVJQ82Msc2dPXg64wjj7pi7Cs
FjBAel65YLP9scfmRtEvEwkhyIAH8y/mUP+kCuC/IKBqJRpe+MaiQ8lPsYRRzgj8oGT2
m+WALYRY+LmZYoEh1nTyUz2T2TF9v/yVswvEc28xFEzO1ekH+wKtATswKmW3YVr6qs2t
ryxvU0JW6q+VWeRsNJlToJxMidNLeoTehObWQfs3vCbaVXVT+RhGBEj4+sVsSx8HHNRT
kxMJYWQvitkIjHNF23a/SP+XY+Y8MKaTeiRLv7PM2KhPTifymIgnGr1aPF9xi+fROELs
ATEw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1759944454; x=1760549254;
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=LChHRkxlgsW5tEOfo4zYomfUmA567rAD6/YemagFv7k=;
b=l3ah+PvRBLDfU7MRYDcAI0iwkuOXIDoz8efOieJ9fK2JPVydZexyZGZTQuk7ViyV1e
3aWjahjVSAstkN/8Qes/X9wCl/Mqm66vbcHIEBPTGOJA3DQHq9A0eKGe2X1jfGf9GKD6
A/Od6Yf3KNxZN6GVUT1IVBQzTPlg04iB/wXr1HU/3CgjdzDBlaEfkpi+OQlXUjmW4RWF
IsBHzUz/PfOn1o5tORpoftQByLUpsptzf4VWXJPjs7Pup4rTz8NFgicpe/kRvxy/8e9e
kc3O2ZtO6lEV9Me2ZKr5QhXLoELxQLIt3fzXFuGJYSYrQ1adsYdBuC3j06jHIISXJ+2R
dFVg==
X-Forwarded-Encrypted: i=1;
AJvYcCXfzYRuPabGBL1K5NuQXoVD298JpVKR8O5rNYUoWCjjVaFyDDKC4w3dc8HweKKYsxp3FwmFXg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YyJ10mIp9h8OctSS5UbHokotP/sz3ff2l8nTW+9cA0zroyf7GSR
t9OVcjf+PSYPY4oF8k0YnsHoDe54r0jvsnNMMcWfyaO6gKpolRSV6/AKa/Qr9g==
X-Gm-Gg: ASbGncvZR3Ko6C3wnDPDlSzl7Tb5LPGU1t2RmxraQun3rs/3eEprN0i1MBi6RVSrPLP
URq3HSWEfgHpQsr7YumHC0WKM+Xu8s9dL7ANUYn5+v7VizhBNEDDyNCWNE+vptBka8J7aIgorWR
pW+Mh4mVD7g/GVtlSCu9CaF+nP5iXeGJjGrMz/ZnCQgFB1TjzPrOKcjqoUAHkvI7FhigrXRMslm
Mnh8wCshP7ID18MOikmJwQKma/tMwkq2W2FMupn7PA6/R7wS+8X04/lAblqqFzHFKjH1APBdIju
CcRzEG6bdGKZLrUTVfGuP9hxVRf4YrXbUwftvHHVV9xE9LiVXUQ/vjqfLSM3QtoAs4SME7Ll2wb
aN3KJcogvx6px9QqymSx/nRvrWfNi0HMjMy1jdNyYZtQqxFROt+T3VYjoNNsnRYmgNgFYYODQaC
9H+aE+ge3yoMeqMcmBluOhR2J0rWZM+p8QPFvq9yOL/5LthX2P5DpOwWc=
X-Google-Smtp-Source: AGHT+IGtsNm6iUrDju0XEDzR3J8e0aZ7oVNV05aSH53tnsqbf3ZZj2kbQUcWqDn1rv2IGjnpdEYQ2g==
X-Received: by 2002:a05:600c:8718:b0:46e:731b:db0f with SMTP id
5b1f17b1804b1-46fa9b08f09mr27629115e9.28.1759944454237;
Wed, 08 Oct 2025 10:27:34 -0700 (PDT)
Received: from pro4 (p200300e0b7062100a4dba41779cb9384.dip0.t-ipconnect.de.
[2003:e0:b706:2100:a4db:a417:79cb:9384])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-46fab656554sm18066285e9.11.2025.10.08.10.27.33
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 08 Oct 2025 10:27:33 -0700 (PDT)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Helmut Eller <eller.helmut@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <87o6qhz6wl.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN>
<87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN>
<87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN>
<86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
<87o6qhz6wl.fsf@HIDDEN>
Date: Wed, 08 Oct 2025 19:27:32 +0200
Message-ID: <m2v7kpnw1n.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: 79584
Cc: 79584 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
oliver.reiter@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 (-)
Helmut Eller <eller.helmut@HIDDEN> writes:
> On Wed, Oct 08 2025, Gerd M=C3=B6llmann wrote:
>
> [...]
>>>> I guess the first question is if global emacs_values are a thing that =
is
>>>> supported or not.
>>>
>>> AFAIU, they are supported, provided that the module adheres to the
>>> protocol of their support: see "Module Values" in the ELisp reference
>>> manual, where it describes make_global_ref and free_global_ref, and
>>> user pointers as an alternative.
>>
>> Yeah, that reads like it is supported, unfortunately :-/. (I find it a
>> bit unsafe to return global_refs as emacs_value interior pointers, and
>> store them as global variables, because _only_ global_refs allow that,
>> but be that as it may. It is what it is.)
>
> Do we need to preserve some form of binary compatibly?=20=20
I'm not sure how that works. There is emacs-module.h.in which is patched
with the emacs major version. Maybe that prevents loading old binaries
that don't fit to the Emacs version being used.
> If we could change the size of emacs_value, then we could use
> something like:
>
> struct emacs_value {
> enum gc_handle_type {LOCAL, GLOBAL} type;
> union {
> struct local_gc_handle local;
> struct global_gc_handle global;
> } gc_handle;
> };
>=20=20=20
> struct local_gc_handle {
> Lisp_Object obj;
> };
>=20=20=20
> struct global_gc_handle {
> size_t key;
> };
>
> Local GC handles are only safe as long as they are on the stack and
> rely on the usual conservative stack scanning. This would avoid the
> emacs_value_storage and associated jmpbuf gymnastics.
>
> Global GC handles use the integer as key in a hashtable (or similar) to
> look up the actual Lisp_Object (or module_global_reference if need the
> reference counting stuff).
Yes, that wouid be nice. Don't know if the larger size plays a role. I'd
say it doesn't, but...
>
>> In any case, I would propose to get rid of the AMS pool. I don't see how
>> AMS could possibly work in conjunction with other pools. IMNSHO, the
>> reference should never have mentioned it because it is simply broken.
>> That's no "don't use in production". Grr.
>
> That the AMS pool is slow is nothing new. But the AMS doc says
> explicitly:
>
> Blocks may contain exact references to blocks in the same or other
> pools, or ambiguous references (unless the
> MPS_KEY_AMS_SUPPORT_AMBIGUOUS keyword argument is set to FALSE when
> creating the pool). Blocks may not contain weak references (1), and
> may not use remote references.
>
> If the AMS pool can't be used with other pools that would be a bug; and
> I would be surprised and quite disappointed because the ability to
> combine pools should be an important feature of the MPS.
Same here, but I cannot figure out how this is supposed to work. Which
can of course be wrong, and I'm just too dumb to find it in the code,
and I didn't study MPS internals before and so on. Anyeay, I now don't
trust ANS anymore. At least some bits of something should be visible in
the code IMO.
>> What could replace it? Let me pull an idea out of thin air, for
>> discussion:=20
>>
>> Replace igc's AMS pool with a new AMC pool, let's call that pool IP,
>> that is used to create immovable objects like global_refs. Global_refs
>> may not move because, if they did, the global emacs_values in modules
>> would have to change, and we don't have access to these, we don't even
>> know if they exist.
>>
>> We make objects in IP immovable by creating ambiguous references to
>> objects in IP when they are created. For simplicity, assume we have an
>> array of pointers to=C2=B4objects in IP that is registered as ambiguous =
root.
>> Adding an object to that array could be O(1) by having a free-list (like
>> marker_vector) and so on. Removing an object could be O(1) by keeping
>> the index where it is stored in the global_ref object. Or the array
>> could be
>>
>> struxt immovable_references {
>> struct entry {
>> void* reference;
>> struct entry* prev_free;
>> struct entry* next_free;
>> };
>> struct entry* free_entries;
>> size_t capacity;
>> struct entry entries[];
>> };
>>
>> (Only for the idea, don't look at it too closely.)
>>
>> Since global_refs must use a make_ref/free_ref pattern I think that
>> should work. And I think it would have relatively low overhead.
>>
>> Using a second AMC pool would be for avoiding some pinned objects among
>> the "normal" ones. Maybe one could even do without, and use the normal
>> AMC pool, don't know. Maybe one should even try that first.
>>
>> WDYT?
>
> The entries in immovable_references would be the current
> module_global_reference objects?
Ambiguous references to them. Just to make sure that the global_refs in
the MAC pool don't nove in memory.
> Or is the idea to make emacs_values be Lisp_Objects and global_refs
> would be pinned Lisp_Objects?
No really. I don't know if that wouldn't require too much work.
emacs_value would remain basically a pointer to a Lisp_Object. As you
said above, the non-global-refs would be pinned by being on the stack,
and the global_ref interior pointers would not change because the
global_ref is pinned with the mechanism above.
> (I wonder why module_global_reference objects are GC managed at all;
> they have reference counts so why not use malloc/free.)
Yeah, that's also a bit strange. Maybe it was easier that way with the
old GC, marking the Lisp_Object they contains, or something like that
maybe.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 17:27:10 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 13:27:09 2025
Received: from localhost ([127.0.0.1]:34086 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6XwT-0005Vr-6T
for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 13:27:09 -0400
Received: from mail-24416.protonmail.ch ([109.224.244.16]:47787)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1v6XwL-0005Um-4J
for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 13:27:02 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1759944414; x=1760203614;
bh=7dWZn6KtL+ryyyiam6J7waphXoc9YYOPeqv3NbUQN9c=;
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;
b=yYH9tOWG4mKOJlwm9Qdt3Y586XkpWmBjySlw6l7iShREOwBzq/Yq5cnmOBEYMX3WQ
vOlryiHFRU8Rz7EdNe2h0g8xzHFUiPyUWitMXLsbfGRYH6UaaBNWbt95wlRe3VqoA9
Uc7ymqaG7ZkkW03ZQA8/DDYKxmUEtp/eGWCywbMjdDBaFbXmAa/pgQAdRpEMMA++xB
dHUhzy8J+/cWMuFkKxazSenFYVDFRYtwRVGZkjYAvLOMc0SqXKXzcFbSgpoSec2Sr4
iQhLMULcodQgBKc2RRE/UzK9VpOfEdURPVixynZKBdqXwtZeGftBQ1hl4lVCt7G72P
dyfgC7WfLeoZw==
Date: Wed, 08 Oct 2025 17:26:50 +0000
To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
Message-ID: <87zfa1ctwm.fsf@HIDDEN>
In-Reply-To: <m21pndpqtv.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN>
<87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN>
<87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN>
<86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 770e6b785007086d0bdeba256b0b0b6af72beffa
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: 79584
Cc: eller.helmut@HIDDEN, Eli Zaretskii <eliz@HIDDEN>,
oliver.reiter@HIDDEN, 79584 <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: Eli Zaretskii <eliz@HIDDEN>, Oliver Reiter
>>> <oliver.reiter@HIDDEN>, 79584 <at> debbugs.gnu.org, Helmut Eller
>>> <eller.helmut@HIDDEN>
>>> Date: Wed, 08 Oct 2025 11:08:10 +0200
>>>
>>> I guess the first question is if global emacs_values are a thing that i=
s
>>> supported or not.
>>
>> AFAIU, they are supported, provided that the module adheres to the
>> protocol of their support: see "Module Values" in the ELisp reference
>> manual, where it describes make_global_ref and free_global_ref, and
>> user pointers as an alternative.
>
> Yeah, that reads like it is supported, unfortunately :-/. (I find it a
> bit unsafe to return global_refs as emacs_value interior pointers, and
> store them as global variables, because _only_ global_refs allow that,
> but be that as it may. It is what it is.)
>
> In any case, I would propose to get rid of the AMS pool. I don't see how
> AMS could possibly work in conjunction with other pools. IMNSHO, the
> reference should never have mentioned it because it is simply broken.
> That's no "don't use in production". Grr.
I wouldn't go quite that far; AMS was probably very useful at some
point, but optimizing compilers make it hard to avoid ambiguous interior
pointers which keep objects alive, and while it probably wouldn't be
hard to fix AMS to support those, it hasn't been done yet.
But that's not the problem here: the problem here is that if you follow
a pointer into an AMS segment, that pointer must be somewhere MPS knows
about. So they're just like AMC pointers in that regard, which means
they're unsuitable for global references that are stored outside of
MPS-managed memory.
> What could replace it? Let me pull an idea out of thin air, for
> discussion:
>
> Replace igc's AMS pool with a new AMC pool, let's call that pool IP,
> that is used to create immovable objects like global_refs. Global_refs
> may not move because, if they did, the global emacs_values in modules
> would have to change, and we don't have access to these, we don't even
> know if they exist.
But they also don't have to be pointers! Making an emacs_value store a
hash index (either directly or by returning a pointer to one) would mean
we wouldn't have to do any GC tricks at all for global refs. For local
environment emacs_values, we'd probably still want to store a pointer.
My first approach was to make use of the unused tag to create a
Lisp_Object type that represents a hash index in the global refs hash.
emacs_value would be a pointer to a Lisp_Object, but if it has tag 1
value_to_lisp would untag it to retrieve the hash index and return the
hash element rather than the original Lisp_Object. The other tags are
stored in the environment and can be retrieved directly.
> We make objects in IP immovable by creating ambiguous references to
> objects in IP when they are created. For simplicity, assume we have an
> array of pointers to=C2=B4objects in IP that is registered as ambiguous r=
oot.
> Adding an object to that array could be O(1) by having a free-list (like
> marker_vector) and so on. Removing an object could be O(1) by keeping
> the index where it is stored in the global_ref object. Or the array
> could be
>
> struxt immovable_references {
> struct entry {
> void* reference;
> struct entry* prev_free;
> struct entry* next_free;
> };
> struct entry* free_entries;
> size_t capacity;
> struct entry entries[];
> };
>
> (Only for the idea, don't look at it too closely.)
So the entire struct would be an ambiguous root, and we'd perform our
own management of it using a built-in free list rather than letting MPS
do it? That seems complicated, and it still means every global reference
would slow down the start of every GC cycle, which is extra user-visible
latency. At least in theory, the hash index approach doesn't do that.
> Since global_refs must use a make_ref/free_ref pattern I think that
> should work. And I think it would have relatively low overhead.
>
> Using a second AMC pool would be for avoiding some pinned objects among
> the "normal" ones. Maybe one could even do without, and use the normal
> AMC pool, don't know. Maybe one should even try that first.
IIUC, pinned objects in AMC pools prevent the entire segment from ever
being freed, and there is no mechanism for reusing it, either, so that's
a permanent waste of memory.
AMC pools aren't really designed for permanently-pinned objects. It's
tempting to ignore that and allow objects to be pinned intrinsically,
without the need for an ambiguous reference to do so, but we'd have to
be very careful to avoid wasted memory.
> WDYT?
I think my preference would be the tagging scheme to make emacs_value
either an encoded hash index or a pointer to a Lisp_Object (as before).
Pip
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 17:24:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 13:24:14 2025 Received: from localhost ([127.0.0.1]:34070 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6Xte-0005HU-83 for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 13:24:14 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35382) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1v6XtY-0005H6-Ou for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 13:24:10 -0400 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 1v6XtM-00021F-HG; Wed, 08 Oct 2025 13:23:57 -0400 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=Z4O23t3UB4KfiuDeHef7GUTQ13dSsuHNqYSUfl3FL8o=; b=d9afu3sMd2/ysEUpT5SN K521TKXOYXMRFtOkLIvgx4x6DhCkGZncR4WiSjapbCSeBzZbdk+qWn4ABviFQq/yjhv76fNROOPhI 32OfI/uTYnYZHbjkFVEdAtguB/1gl8m/OS7adxKrPJXWs+XyJ1/6tutWhoo8kMqIPQ5//HXZ0+gHQ +YOgqPtCV51M9F32qrB/xiL+0OxNlVTeW8T0+uIiQdg7bo/6OrqlxHaKR3Q3KonuLqgXrgtGzyAa+ 7ksF2kozgAXAp++5iItIYRvUlKhXnbli4pn5WXvkzZIf9v/gDIQJp03Jga/GOs30/mKodOseyL6PP yjDP/rvFyDGuZQ==; Date: Wed, 08 Oct 2025 20:23:52 +0300 Message-Id: <86347tb93r.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Helmut Eller <eller.helmut@HIDDEN> In-Reply-To: <87o6qhz6wl.fsf@HIDDEN> (message from Helmut Eller on Wed, 08 Oct 2025 18:37:30 +0200) Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN> <87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN> <87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN> <87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN> <86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN> <87o6qhz6wl.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: 79584 Cc: gerd.moellmann@HIDDEN, pipcet@HIDDEN, oliver.reiter@HIDDEN, 79584 <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: Helmut Eller <eller.helmut@HIDDEN> > Cc: Eli Zaretskii <eliz@HIDDEN>, pipcet@HIDDEN, > oliver.reiter@HIDDEN, 79584 <at> debbugs.gnu.org > Date: Wed, 08 Oct 2025 18:37:30 +0200 > > On Wed, Oct 08 2025, Gerd Möllmann wrote: > > [...] > >>> I guess the first question is if global emacs_values are a thing that is > >>> supported or not. > >> > >> AFAIU, they are supported, provided that the module adheres to the > >> protocol of their support: see "Module Values" in the ELisp reference > >> manual, where it describes make_global_ref and free_global_ref, and > >> user pointers as an alternative. > > > > Yeah, that reads like it is supported, unfortunately :-/. (I find it a > > bit unsafe to return global_refs as emacs_value interior pointers, and > > store them as global variables, because _only_ global_refs allow that, > > but be that as it may. It is what it is.) > > Do we need to preserve some form of binary compatibly? If we could > change the size of emacs_value, then we could use something like: I'd _really_ prefer not to force people out there to recompile their modules if they want to use IGC. I'm guessing many users download precompiled modules and don't have the ability to recompile them anyway. So it would be really good if the same module binaries could work with both flavors of GC.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 16:38:04 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 12:38:04 2025
Received: from localhost ([127.0.0.1]:33892 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6XAx-0002Dj-R0
for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 12:38:04 -0400
Received: from mail-wm1-x32e.google.com ([2a00:1450:4864:20::32e]:47443)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>)
id 1v6XAa-0002B4-VH
for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 12:37:43 -0400
Received: by mail-wm1-x32e.google.com with SMTP id
5b1f17b1804b1-46e47cca387so426375e9.3
for <79584 <at> debbugs.gnu.org>; Wed, 08 Oct 2025 09:37:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1759941453; x=1760546253; 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=eJhLrFbEa4VFsUhom7j8gpv8ddrUvdEmnDbKGStkaEw=;
b=BF+UtaPQ08SPAC357rCax12MULaz/Jw/Vqx9iFZOx3fpNiPEt50ufrfB2dxdaLkaml
Dyt85vT4YgBCfrWLFSl0nlosmoBgnUPHM4lN8UtBJ3jcmvjDaSJ4PWexQz5hL8ulfOZD
W/lLXUH1zl5F/GNAZLuSK56G3o7Hb1Y92O2eTaHptzlejf9EpK1Vn9zY4I09Ut7phszZ
JmfFFrr/slLVomWwFDLd3r3rN3tM1UPhtt+StITsSkR2cSVzDDT/qvSs8Kl1W946FaC0
IELWSZJsK091ZfHm1l/6GfCnI0PcBQ9P0ieIQJesefh04AGT4fMUvTRQ7/yBkSALIrEd
SD9w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1759941453; x=1760546253;
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=eJhLrFbEa4VFsUhom7j8gpv8ddrUvdEmnDbKGStkaEw=;
b=YnrL2ys7ubawD9G6BDkXSDBL/3awh/CKrenctPLQCOebJUmppR0ZSNNfzZl4nXrY7g
TwVQcZa0hNVVQyOYWwuUoBX+6rcdeU9BICf0SSysK6x4BDd3PfcvZvaTGADnjMGcLy1N
dwVYj5jmxCs0d1ZHZdND+ru3h/bwSPOGnob+7/G2zc022Vobd91O1mt6DwsCO/Qo+xwX
IUGZf81kmLzBslgFR+179WF+HM3ywHmcV7txp5rvahU9h+mpQCVUP0aqefmo0Ekw71A+
2VwWa/kiIcGzCkP7wGDouz0h3MHupNeIf+YlAUVjb6csKXLowM+fU+AHho43eMFZ2PI7
ozbw==
X-Forwarded-Encrypted: i=1;
AJvYcCWAR+f5g01/kucs3VVHel50aeqGMT4ocn1/SlrnZtaXNuN0KePxbd77D8trBuOhM/CLCzpCyA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YzpHSUnt957tBMdrLmOuC/FbQupgXWnmP25ASY7uTaNnFdI8HKM
OuO7APusuXqHrEGqH9U6K27OKUZ8k6gf2cYeCNRUbm0MVdetK/u2Ijs+oU3yGA==
X-Gm-Gg: ASbGncvV1gRWmnacRVHateu9qVxtGNsZtWuHogwb+BjtebRcpio03wQPBH4gy/I3u8y
ySs4+v30lymuOtSKRG9bX3OXFBxN6k8FtOn4v7IQfHjBenTLG6HfIHNFh0fPvuZkvA8EYXt+hSm
woaPihYvkiNEbaE5cWTueu+a+76PIq3HBFqEEq4R7XRhXZkaoE+lMJuJTvsq/KfRnMgZhsLbew5
Z5cmjhgzYcAkBHE5Q9OwCNZujQtmwwbaGgyABMSQ+yAvkX2dtareb8QhNMEA6vgqY3xdpZAK4bX
132quaRg0Pv1FZYll0qaEywPFbDy7Ix1s4H1BGtMGAkoVMS7721welPVcC3hA78EcB+8X1UwBSr
LmQqmJPfEGFbgJMxsz3c5MFl0aFAqFY7tfzPsf22TW3TU
X-Google-Smtp-Source: AGHT+IF/9GmiJUWAtanN/JIbJYCylDMS23NXBhEZZTGmTwbcPG1gu4fTm+porXiXcpmdKU79mxoZHA==
X-Received: by 2002:a05:600c:1c23:b0:46e:32a5:bd8d with SMTP id
5b1f17b1804b1-46fa9a892d7mr29862235e9.3.1759941453055;
Wed, 08 Oct 2025 09:37:33 -0700 (PDT)
Received: from caladan ([31.177.112.212]) by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-4255d8a6c54sm31013659f8f.11.2025.10.08.09.37.32
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 08 Oct 2025 09:37:32 -0700 (PDT)
From: Helmut Eller <eller.helmut@HIDDEN>
To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <m21pndpqtv.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN>
<87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN>
<87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN>
<86h5w9bu8c.fsf@HIDDEN> <m21pndpqtv.fsf@HIDDEN>
Date: Wed, 08 Oct 2025 18:37:30 +0200
Message-ID: <87o6qhz6wl.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: 79584
Cc: 79584 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>,
oliver.reiter@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 (-)
On Wed, Oct 08 2025, Gerd M=C3=B6llmann wrote:
[...]
>>> I guess the first question is if global emacs_values are a thing that is
>>> supported or not.
>>
>> AFAIU, they are supported, provided that the module adheres to the
>> protocol of their support: see "Module Values" in the ELisp reference
>> manual, where it describes make_global_ref and free_global_ref, and
>> user pointers as an alternative.
>
> Yeah, that reads like it is supported, unfortunately :-/. (I find it a
> bit unsafe to return global_refs as emacs_value interior pointers, and
> store them as global variables, because _only_ global_refs allow that,
> but be that as it may. It is what it is.)
Do we need to preserve some form of binary compatibly? If we could
change the size of emacs_value, then we could use something like:
struct emacs_value {
enum gc_handle_type {LOCAL, GLOBAL} type;
union {
struct local_gc_handle local;
struct global_gc_handle global;
} gc_handle;
};
=20=20
struct local_gc_handle {
Lisp_Object obj;
};
=20=20
struct global_gc_handle {
size_t key;
};
Local GC handles are only safe as long as they are on the stack and
rely on the usual conservative stack scanning. This would avoid the
emacs_value_storage and associated jmpbuf gymnastics.
Global GC handles use the integer as key in a hashtable (or similar) to
look up the actual Lisp_Object (or module_global_reference if need the
reference counting stuff).
> In any case, I would propose to get rid of the AMS pool. I don't see how
> AMS could possibly work in conjunction with other pools. IMNSHO, the
> reference should never have mentioned it because it is simply broken.
> That's no "don't use in production". Grr.
That the AMS pool is slow is nothing new. But the AMS doc says
explicitly:
Blocks may contain exact references to blocks in the same or other
pools, or ambiguous references (unless the
MPS_KEY_AMS_SUPPORT_AMBIGUOUS keyword argument is set to FALSE when
creating the pool). Blocks may not contain weak references (1), and
may not use remote references.
If the AMS pool can't be used with other pools that would be a bug; and
I would be surprised and quite disappointed because the ability to
combine pools should be an important feature of the MPS.
> What could replace it? Let me pull an idea out of thin air, for
> discussion:=20
>
> Replace igc's AMS pool with a new AMC pool, let's call that pool IP,
> that is used to create immovable objects like global_refs. Global_refs
> may not move because, if they did, the global emacs_values in modules
> would have to change, and we don't have access to these, we don't even
> know if they exist.
>
> We make objects in IP immovable by creating ambiguous references to
> objects in IP when they are created. For simplicity, assume we have an
> array of pointers to=C2=B4objects in IP that is registered as ambiguous r=
oot.
> Adding an object to that array could be O(1) by having a free-list (like
> marker_vector) and so on. Removing an object could be O(1) by keeping
> the index where it is stored in the global_ref object. Or the array
> could be
>
> struxt immovable_references {
> struct entry {
> void* reference;
> struct entry* prev_free;
> struct entry* next_free;
> };
> struct entry* free_entries;
> size_t capacity;
> struct entry entries[];
> };
>
> (Only for the idea, don't look at it too closely.)
>
> Since global_refs must use a make_ref/free_ref pattern I think that
> should work. And I think it would have relatively low overhead.
>
> Using a second AMC pool would be for avoiding some pinned objects among
> the "normal" ones. Maybe one could even do without, and use the normal
> AMC pool, don't know. Maybe one should even try that first.
>
> WDYT?
The entries in immovable_references would be the current
module_global_reference objects?
Or is the idea to make emacs_values be Lisp_Objects and global_refs
would be pinned Lisp_Objects?
(I wonder why module_global_reference objects are GC managed at all;
they have reference counts so why not use malloc/free.)
Helmut
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 14:40:05 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 10:40:05 2025 Received: from localhost ([127.0.0.1]:33571 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6VKm-0003Bz-IO for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 10:40:04 -0400 Received: from mail-24416.protonmail.ch ([109.224.244.16]:52563) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <pipcet@HIDDEN>) id 1v6VKg-0003Ac-R5 for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 10:40:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1759934389; x=1760193589; bh=5ASj31ZPxlpfr/5re2XwdbwxeCnKO6xn5qNBA5OlUX4=; 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; b=MydLDAvL82wyjJeaSW5MPNI1QKz74wuGMp10wRJ3vbw25nUDwtcjP61QY0tBUZm+n TqreTDKAyIob/XvI54mjue9IVxsKxBVafLanC9g26CpMguNIZG71sL3SxV0V0a85RN NyvcP4wNuy4/u4BCR9ozDEUqwMsgDJVvhC0RGaSQEC0wQhqvLC+rhxjDu3ate9c089 SkjGjCw9eArqWBJ8LqjSQ3btyc1wg81xcvytAoDkaJfB8uec/HaKeWdGP/2M4HTLOX Mts7V6maMQ2nH5i/6qxe+Zmb17Vg7FV5evA1EraKJf4ButH8+u5mzyJNwnJI2K6vhW It4mkXNENfKAQ== Date: Wed, 08 Oct 2025 14:39:12 +0000 To: Helmut Eller <eller.helmut@HIDDEN> From: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm Message-ID: <875xcpe9y5.fsf@HIDDEN> In-Reply-To: <87ikgqczdm.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN> <87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN> <87ms62ency.fsf@HIDDEN> <87ikgqczdm.fsf@HIDDEN> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: a14cc2f58fc337b160149146dec5619d6e14e1ce 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: 79584 Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Oliver Reiter <oliver.reiter@HIDDEN>, 79584 <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 (-) "Helmut Eller" <eller.helmut@HIDDEN> writes: > On Tue, Oct 07 2025, Pip Cet wrote: > > [...] >> I've finally been able to reproduce this (thanks again for the reports, >> and for providing the right compilation options), and I believe I >> understand what's happening now. > > Do you have reproducible test? Not a good one. What I do is to run: (require 'vterm) M-x vterm in the vterm, "find /" (run-with-timer 0.0 0.01 #'vterm--delayed-redraw (get-buffer vterm-buffer-n= ame)) and wait for... a while (maybe ten minutes, on average?). I'm not sure whether reducing the pause time to 0 helps or not, TBH. >> An alternative approach would be to redefine emacs_value to be a hash >> table key, probably a fixnum, which is used to find the global reference >> in an additional ordinary hash table. That would mean that the hash >> table vector would benefit from proper protection; it'd slow down >> modules very slightly, but it'd speed up the important case where a >> module creates many references but isn't actively using them. > > This is quite tricky. It seems that the problem can only happen if the > module_global_reference is accessed while a trace is in progress. So a > simple igc--collect can't be used to trigger the problem. That's my understanding as well. You need to be in the middle of a garbage collection cycle, and it's not obvious to me what you can do to hit the bug quickly. Pip
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 11:37:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 07:37:30 2025
Received: from localhost ([127.0.0.1]:60667 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6SU6-0008HK-3G
for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 07:37:30 -0400
Received: from mail-ej1-x62e.google.com ([2a00:1450:4864:20::62e]:55528)
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 1v6SU1-0008Gq-C3
for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 07:37:27 -0400
Received: by mail-ej1-x62e.google.com with SMTP id
a640c23a62f3a-b4f323cf89bso401828966b.2
for <79584 <at> debbugs.gnu.org>; Wed, 08 Oct 2025 04:37:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1759923438; x=1760528238; 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=5l6f4I/mSFGUqaeSzsEl5PRyvpw/WOn1tV75im3oqu0=;
b=Z+lyZ88mFcXoMhfe2WIKz5Vg/SovweE1+zQOdEp0U5DgbZecTW96i9che/ixdNCFV9
7/An4H4Xa7fD/dtmm0C7TrdqAzDXnEpZRVOZgIelYtDKX3nf+vpgkeqiobmMuoOxI7CK
OgvPg2QlHRaI/YM5n8J7DJ/xr5sriOzURW+AoWJ/LqZKRulJAFgXMoJiZc0jV2VI5gS8
HeFKdh9wWuCU11X/xTl+4iy1ycsx98Zj3ieQoZuLKT/DcXhnBUFZmrgt5HUb+jn93zWD
/3h9KEhCq0ra5gHMT26g6kV1HrYKFytPtu4tYnpb8XuSjLrUrZJtU4BAHtUf7JE6XA7E
fS5A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1759923438; x=1760528238;
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=5l6f4I/mSFGUqaeSzsEl5PRyvpw/WOn1tV75im3oqu0=;
b=DcpT2U3/cr1Vv9DgoDjgM7NXP6D+eXKcwti2zA+zrqkZgqMQeDlVloFmaZxth6NScl
ygZg+yZ3pj4Yf6ydSwnlTO+Hjoc9QqjaU/Pi97ghBkoTmIBstaWRBLQ2JeOAiGJ6GITh
sUUHYMJGPFybe9vReMiE+nI9P0JRSxmRVoCDMyHksVrcXu/x4FBxBl1xITQKQ+20SE6e
Lg1fP6tcxf9Y6ZspeFkWuiZCdoF1Erir6TxoNxwc27k3nn9Mqv3bELxx+mE4LbpXWbmJ
deJB2c7z1XvTa12czM2oYd+nBjWM7MbGfTxiV068N8XaDotsmOy09C8H45uRDzaLUQN4
7hdw==
X-Forwarded-Encrypted: i=1;
AJvYcCWEAZwGAvgnnhXg/dQ2Qs0bweq4uuZf1sp/c7+g0OeqBXNH7o55P+N9/UslCtk7Zr0LndxPog==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YySyfwCns6+KW1KERcxsqYflWlyUUQa89ZBPjE5610j3qNq/YA4
ob0wRNHft+ANu2WTVazfdJoTvkBGSo7c6/SUW7zzOuP2BqCUJAughtoo
X-Gm-Gg: ASbGnctwrRLnHZTz6DlLIJyenke1nYJT/uyc1JQe3vSoNA+Bxt13YBPb+tvnnPG0sCP
BUhe8V5Unku7wJUn0sEYP7hguqh0AFzK40RinPhv5nByxyw6S868QqCm411aNb71a8Mt/sK05DV
H1rCzj+7Ouw3mrEE/R/iJLGZF3Gwz5ukzLNJ3k2cNRA32+G2AoQdy5QNZ15yGbqiTM0gD3hM/IB
yjHoRP54t/xXr2sRM8C6seyJiElKbH/vWCNoYYvhpsnneUWyCtgo/BfJ/QsRoRop4V6gzrj+PhB
PTyHE3ypBKNHCkapJP5mn+3I7eP1s82a7eVu8/zW1Bp7LzSRPM80dXXo7RplOyNQnHf0iSJDJWB
Po42fYg2i3RnGTQ+/qnfwEp5Aolwv19C98lvMJ6lnncRtAyh0rMblYhygi7IpR4c0RZ314KDOO4
IQZG6Cm3manvu47QbZA2BWNpx7oJBMp2Wqhl4KN0+jZVDD4u3PMmFZTrc=
X-Google-Smtp-Source: AGHT+IFLUQkbbUheLSLuljdRuVfYKM09pstUTk4sR14+ddmf+Kv2vrdmF9YVWTzlJcYiC5W9H08MuA==
X-Received: by 2002:a17:907:1c15:b0:b40:e46e:3e0d with SMTP id
a640c23a62f3a-b50abfd6af4mr373218266b.46.1759923437484;
Wed, 08 Oct 2025 04:37:17 -0700 (PDT)
Received: from pro4 (p200300e0b7062100a4dba41779cb9384.dip0.t-ipconnect.de.
[2003:e0:b706:2100:a4db:a417:79cb:9384])
by smtp.gmail.com with ESMTPSA id
a640c23a62f3a-b4865986505sm1629402366b.23.2025.10.08.04.37.16
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 08 Oct 2025 04:37:17 -0700 (PDT)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <86h5w9bu8c.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN>
<87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN>
<87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.fsf@HIDDEN>
<86h5w9bu8c.fsf@HIDDEN>
Date: Wed, 08 Oct 2025 13:37:16 +0200
Message-ID: <m21pndpqtv.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: 79584
Cc: eller.helmut@HIDDEN, pipcet@HIDDEN, oliver.reiter@HIDDEN,
79584 <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>, Oliver Reiter
>> <oliver.reiter@HIDDEN>, 79584 <at> debbugs.gnu.org, Helmut Eller
>> <eller.helmut@HIDDEN>
>> Date: Wed, 08 Oct 2025 11:08:10 +0200
>>=20
>> I guess the first question is if global emacs_values are a thing that is
>> supported or not.
>
> AFAIU, they are supported, provided that the module adheres to the
> protocol of their support: see "Module Values" in the ELisp reference
> manual, where it describes make_global_ref and free_global_ref, and
> user pointers as an alternative.
Yeah, that reads like it is supported, unfortunately :-/. (I find it a
bit unsafe to return global_refs as emacs_value interior pointers, and
store them as global variables, because _only_ global_refs allow that,
but be that as it may. It is what it is.)
In any case, I would propose to get rid of the AMS pool. I don't see how
AMS could possibly work in conjunction with other pools. IMNSHO, the
reference should never have mentioned it because it is simply broken.
That's no "don't use in production". Grr.
What could replace it? Let me pull an idea out of thin air, for
discussion:=20
Replace igc's AMS pool with a new AMC pool, let's call that pool IP,
that is used to create immovable objects like global_refs. Global_refs
may not move because, if they did, the global emacs_values in modules
would have to change, and we don't have access to these, we don't even
know if they exist.
We make objects in IP immovable by creating ambiguous references to
objects in IP when they are created. For simplicity, assume we have an
array of pointers to=C2=B4objects in IP that is registered as ambiguous roo=
t.
Adding an object to that array could be O(1) by having a free-list (like
marker_vector) and so on. Removing an object could be O(1) by keeping
the index where it is stored in the global_ref object. Or the array
could be
struxt immovable_references {
struct entry {
void* reference;
struct entry* prev_free;
struct entry* next_free;
};
struct entry* free_entries;
size_t capacity;
struct entry entries[];
};
(Only for the idea, don't look at it too closely.)
Since global_refs must use a make_ref/free_ref pattern I think that
should work. And I think it would have relatively low overhead.
Using a second AMC pool would be for avoiding some pinned objects among
the "normal" ones. Maybe one could even do without, and use the normal
AMC pool, don't know. Maybe one should even try that first.
WDYT?
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 09:48:09 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 05:48:09 2025 Received: from localhost ([127.0.0.1]:60420 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6QmG-0006ll-Ku for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 05:48:08 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:43008) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1v6QmD-0006lD-7C for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 05:48:06 -0400 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 1v6Qlj-0000FV-Gd; Wed, 08 Oct 2025 05:47:52 -0400 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=n44x59qOCyuozs3mOJU4fLoIAEnqQUs7AIkri2qLJu8=; b=YqlVJcBVOHPG7QiwdoQv Quo61xfbPPSSOmZezemIN/QalZiOTscrUOGhgdBMRDLzKMbgEQ2qfpySmUtMnae4/YhArcP9pSWbV q9aXCd1H5zhYyy4ZRJ6COPnHOcmmKYPXe6KLsGWxlDyz59D6zgTSMuN6zPfOZNbtOhOFw3XSRi+Ol qN0EEoGMC0AxFmmD2qBtkdcIVPoP67RpVZY/SnwP0J6cgaVUO2PM5V5nIZhIX94uQuCR4eRluKeP+ bA9Hcw0QGfu8/9duAvdgihK782zKebqihB67U3HvEokTGty5GjBh7Dp/MRTOW4j8mryQNlRR2ZPNN gb7NCs5/dogvmg==; Date: Wed, 08 Oct 2025 12:47:31 +0300 Message-Id: <86h5w9bu8c.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> In-Reply-To: <m27bx5pxqd.fsf@HIDDEN> (message from Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= on Wed, 08 Oct 2025 11:08:10 +0200) Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN> <87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN> <87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN> <87ecrdepx7.fsf@HIDDEN> <m27bx5pxqd.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: 79584 Cc: eller.helmut@HIDDEN, pipcet@HIDDEN, oliver.reiter@HIDDEN, 79584 <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>, Oliver Reiter > <oliver.reiter@HIDDEN>, 79584 <at> debbugs.gnu.org, Helmut Eller > <eller.helmut@HIDDEN> > Date: Wed, 08 Oct 2025 11:08:10 +0200 > > I guess the first question is if global emacs_values are a thing that is > supported or not. AFAIU, they are supported, provided that the module adheres to the protocol of their support: see "Module Values" in the ELisp reference manual, where it describes make_global_ref and free_global_ref, and user pointers as an alternative.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 09:08:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 05:08:22 2025 Received: from localhost ([127.0.0.1]:60321 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6Q9l-000499-Kc for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 05:08:22 -0400 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:59707) 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 1v6Q9h-00048i-Py for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 05:08:19 -0400 Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-46e6c8bc46eso46376505e9.3 for <79584 <at> debbugs.gnu.org>; Wed, 08 Oct 2025 02:08:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759914491; x=1760519291; 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=XpHmrjgjwMoKG87GqZqLt7TLOzFfNZbLrfuiaLOm5ow=; b=LV/Z1xzZ68kz6gN/7E/c7LfLSnDcvMjcO55m9OvaxcKI5PfZQWUPFRtyIGvLZMb/mR Gm7c2WLrXRd/QRWanPO0qwnTPm9RWVRXSKmTbAAJGVmLpNb8RUtoq+eOLdjhmi1moqaQ viqPkAqI46X2DTjeqh9xTgVH9P7p0dLfPuh7iHI2G4I5CT9pD3R5ARLWkkyPZFii6tOQ 0SUhuSm+G4f/1HY+CoEzHcd6IgyfFhq6VGKyXq7HbJSIzWrIhPG3SNzs7uf6qBoyTG1W Br24CHMfTcX5SezajaD1tZIryjyic6E8m6TGn1pEzITHcrUAYGfA2OGIEOoplTc4Oonr AGUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759914491; x=1760519291; 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=XpHmrjgjwMoKG87GqZqLt7TLOzFfNZbLrfuiaLOm5ow=; b=RXtaShmLxoCr4cXC7WcnNFCt1Fotgh96qG+G9dFXA4BgKSYit0CKKf+nRbm0j6kXx8 UFTecWA4seuN4VR56kBSu9QoHGpR0zgUW5RQpqIl75l1nJ0OT13WlS1JeMM+akRMK2sJ xoZ+Ljzk0ItwBXgs05KAvmNFfoyfaOhyXonAmCngeFLQt/nhrqGoZTS5qVushKsnTOVu CWdQsaeBAStc4bNd6hJ2dW7XoIloX3g1lF5pL9bsBar2EXcKtITq1BHaEM2u0O/ZHeb9 L01r9nPNcm7omyWkOY0uwRj09C/VBWIL9mB1SMvH+cztYfwqeK65vyRqB5M8w1UCNddw wAYQ== X-Forwarded-Encrypted: i=1; AJvYcCUnPhEBM65OVVZvhGCTpL5HKlR/w0BzlZMKE8KpyCGzv+VTu5sykqQr0XmCAMuQWAd/j3ITRA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzpDY8KzdNKzII4Tuw8XLavDkWJfHSvzd58UIPKY9AFfPnbUW5Z oBhNtwKlgxspWotWHbCJdW0Hw8FAkUJ1ZiwKXBezU7D6wHtW6qMMFP6q X-Gm-Gg: ASbGncvGy/SKEwe0rH/fxgYxLt7d8+EBAdyGz+YdqsVfVTNsHgypWLG6yUi6A20Abtc LWHz5+ES//43ONzASxENyBBM4de/LaSOXjZ1kJkV9VcimlekKOJy9XKQ6182292MHwJbOSRlUj6 4h6U4oqYFVSO7v1ip8w6pXH9V8IySo7Hp9eaIafhKO3FsxtRRzFoGL6fXLk4C0P/oSk3gAdUdAB 5L20v6Z98GV63a4M5WHDMq2LwQCfmnFpC4s8qeJWJhynqka5pYnWFmJeblIaLop2UHzUwaeirNn JniJWupZOg/HuCulRT/byW6gNjTxFlT5VsYJT9DA/b8ayifhcNVr2acG+WEJaj+bDRLaktuf7PQ wO0rsHXXsPnlJOEXS3/m8SPwlQbSFI2P9JFpnh2vUjbjzZuoHkyF4Y3S7GyNYAXz+Tuc0c4McKZ vpd6FfySuxVdVXpGr7A+Z2fLOir2reyqK4C+Fmf8tciFSL+RIMwA2V2+k= X-Google-Smtp-Source: AGHT+IFVrI+QWOiHRSmt+SSSqte9Pwmg8QeollVPkKw9MZn1DbUiEb9KAd2+LfQLK4qXfvW7fj5L1A== X-Received: by 2002:a05:600c:154a:b0:46e:5cb5:20df with SMTP id 5b1f17b1804b1-46fa9aa6985mr26593535e9.16.1759914491435; Wed, 08 Oct 2025 02:08:11 -0700 (PDT) Received: from pro4 (p200300e0b7062100157076a399046d07.dip0.t-ipconnect.de. [2003:e0:b706:2100:1570:76a3:9904:6d07]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-46fa9c07cbasm28892925e9.7.2025.10.08.02.08.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Oct 2025 02:08:11 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <87ecrdepx7.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN> <87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN> <87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN> <87ecrdepx7.fsf@HIDDEN> Date: Wed, 08 Oct 2025 11:08:10 +0200 Message-ID: <m27bx5pxqd.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: 79584 Cc: Helmut Eller <eller.helmut@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Oliver Reiter <oliver.reiter@HIDDEN>, 79584 <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: > >> Pip Cet <pipcet@HIDDEN> writes: >> >>> The way MPS works (if I understand it correctly, that is; corrections >>> welcome) is to do as little as possible when it starts a GC cycle: it >>> starts with the roots and ensures that all objects reachable from the >>> roots are either protected or have been fixed. It does not, in >>> particular, fix all mark-and-sweep segments automatically, just those >>> objects which are directly referenced by unprotected roots. >>> >>> The "directly" is important: in our case, there's a root referencing a >>> hash table which contains the global refs, but the hash table lives in a >>> protected (AMC) segment. That means MPS doesn't inspect it until it has >>> to lift that barrier, but the module goes behind our back and accesses >>> the emacs_value (a pointer to the Lisp_Object content of a pseudovector) >>> directly, using a pointer into the unprotected (AMS) segment that MPS >>> doesn't know about. So it gets unfixed data, which points to dead >>> objects. >> >> Hi Pip, >> >> Sorry, I have only skimmed over the whole thread, but from what I've >> seen, and from what you write, I wonder a bit if it could perhaps be the >> problem that I can't read. Reading the AMS pool reference again, I see >> now that it says >> >> Blocks may only be referenced by base pointers (unless they have >> in-band headers). > > That's true. It's actually a bit more complicated than that: ambiguous > interior pointers are allowed (they don't cause crashes), but they don't > preserve the objects they point to (I don't understand whether that > means accessing data through them is fundamentally unsafe, or whether > it's okay to do so as long as you ensure that another reference keeps > the data alive). > >> In this case, the module_global_reference pseudo-vectors live in AMS, >> and emacs_values are interior pointers. > > But emacs_values live in the module's heap or data section, and MPS > doesn't know about them, so they cannot preserve data no matter what > they point to. > >> Could that be related? Where did the emacs_value in your case come from? > > A global variable declared by the module, in my case: elisp.c in the > vterm module declares a number of those. Woah, I didn't know emacs_value was used like that! Is that even allowed by Emacs' module API? I mean, what protects the global objects in elisp.c in case of the old GC? > However, I do think your observation means that putting cons cells in an > AMS pool would be very tricky, since those are sometimes kept alive > through a stack pointer to the CDR cell, and AMS doesn't allow for > that. Even changing the grain size doesn't work because the cdr pointer > would then be unaligned and unaligned ambiguous pointers are simply > ignored. > > As the documentation states: > > AMS is not currently suitable for production use. > > I'm afraid that's true. Me too, see elsemail. That doesn't look good. I guess the first question is if global emacs_values are a thing that is supported or not.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 08:56:29 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 04:56:29 2025
Received: from localhost ([127.0.0.1]:60285 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6PyH-0003El-6r
for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 04:56:29 -0400
Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]:48568)
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 1v6PyE-0003EC-Vi
for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 04:56:27 -0400
Received: by mail-ej1-x634.google.com with SMTP id
a640c23a62f3a-b2e0513433bso1114983466b.1
for <79584 <at> debbugs.gnu.org>; Wed, 08 Oct 2025 01:56:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1759913780; x=1760518580; 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=E7GkMNw8HccncUoUO+Ix4IYUgO36WE7Qo7718FrJ3KM=;
b=nnJf4t9DVe2JFiNprYDlxo6C40EGPPai9u4Fq60y+hnh95+6EdhymHmSYLmSqF1aK7
Q+fyixzzC3oMeapRblJlXpvtNom/CkZ8w+/UZNOTjfTXy47nVEBP2kyA7/y5hUtTDJ6i
I6BF5H3Xq5myiP+aW3LTW0IvmnupxtqGuvK1c3I9N11w4jJhnVRE34TgANeatQyC7pz+
nXDQ4392mdMT0RCruCU0VgiD4yKfpBx/mGe4V5dV6xXNDVlrNNKNJwUfoRRqj0PKzwZF
fCmb1EUXqj0dMsmA1B8J+RZDjijd+/7F8COIA8rYCc20nzRDMHBF+M7AmARCGv671v9I
shhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1759913780; x=1760518580;
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=E7GkMNw8HccncUoUO+Ix4IYUgO36WE7Qo7718FrJ3KM=;
b=n+Q0i6IAQt5h5wr9mdlxOEzvpAWoW8pMXMeaP2r1EdO9DcrRWhgw5Cdt7BzR9Z55uM
eG5mEdkZ7OgoTWx0QB9LxjmGHr3UWv0kjhreF22NzbHfiGR/LvVFeK4TeIm63mddN670
3Q1HqSYtgurXycaRDTcTX0kcevp4AeJfXitcR4jaEIXPWLYU/egWPpLt5iiGkX0DJ+Qc
O5+F+UTak3xyr2Ie5KPZDZWFlIsyQGpKj7BR7OfpxWLUbUxybOldaG+g2DBmx5WFRreT
SBpmAW4o6Iuf+W525Q5UdzDIAlbdm2V9y0BZL5zR3U/SqmBGfZt59opBWygoRsj5Ep3R
Urug==
X-Forwarded-Encrypted: i=1;
AJvYcCUukHMjCnTns2VdF3DfJ1CJb75kc1JFd94wQZQgxQRf+rKcAC2yHCs1baxiDtaWctt7Gm6lZA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yw9ssBfZNAVHHaRS/Jt/sPvy4tCbvDdsHzmMVDvi2usr2dcKRMV
nwdPSwJGrUoh+cU6wSGDxX91FOKtkrlNNGSjozofqsH3074hVp/rCFC3D3U1Yg==
X-Gm-Gg: ASbGncvrkn7JZP6Fs6nvaXV39kNKm/rrtCAmILWy/zryuE1C6F3EIWJ6mzDMb4V4x0v
dWORoLBV1AvJB1UB9hWflYC4Cg0WeN8tZtBHqubNbGRUvFwOvLHEV1Zj/OUY64z3s+BkKY0d5VG
jN8I5qG+9lcNf3e6Hmt48EsKkjCEoy2k7+czgF1QlYE+K7eYAj4U4kADjeRKtwC7VvpTBVwNmko
lw0nZHvUDE/KYOjPC/mghnfWPFeD5UCGot4MgZlV7cEiYAzoIvqksX+tlwUnLO10t2wNhp+yQ+Q
ECoBk5O3TFYGzn9OGiAaPgrdo1l3M1VG3bXHixXOJ9tj+ez4KCbz526pQryAqGbSjnSNm32IDDX
+Sp9pz6nbyJfICITEcAeigV4aGE6YifIeHRM/59owMQEskXqsz/Lj+guWoLVW+jekDtK1fHeQna
syrl+8GcyVSAGvWZsvJTf28N244mVP9QOljd7dj2N3559B1odMDAEITNo=
X-Google-Smtp-Source: AGHT+IHrO1d8XS5A5gSkPOpNx6JwZ0Kn+yWZO0UF3Cujw10VMKKA9yrQT0rJNicIgmeg8PWbiPs+Eg==
X-Received: by 2002:a17:907:7ea8:b0:b46:31be:e8fd with SMTP id
a640c23a62f3a-b50aae8dca4mr287172066b.26.1759913780500;
Wed, 08 Oct 2025 01:56:20 -0700 (PDT)
Received: from pro4 (p200300e0b7062100157076a399046d07.dip0.t-ipconnect.de.
[2003:e0:b706:2100:1570:76a3:9904:6d07])
by smtp.gmail.com with ESMTPSA id
a640c23a62f3a-b4865a7ee4esm1592159566b.28.2025.10.08.01.56.19
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 08 Oct 2025 01:56:20 -0700 (PDT)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Helmut Eller <eller.helmut@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <87tt09bydf.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN>
<87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN>
<87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<m2o6qiowat.fsf@HIDDEN> <874is9dhj9.fsf@HIDDEN>
<m2jz15q2d0.fsf@HIDDEN> <87tt09bydf.fsf@HIDDEN>
Date: Wed, 08 Oct 2025 10:56:16 +0200
Message-ID: <m2bjmhpya7.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: 79584
Cc: 79584 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>,
Oliver Reiter <oliver.reiter@HIDDEN>, 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 (-)
Helmut Eller <eller.helmut@HIDDEN> writes:
> On Wed, Oct 08 2025, Gerd M=C3=B6llmann wrote:
>
> [...]
>>
>> I've read the code a bit now, and I get the feeling that the docs are
>> wrong. With all caution, since I have always refused to study the MPS
>> code more than absolutely necessary:
>>
>> In amsSegFix, I see that "shields" are used, at least in some cases.
>> That should be something like mprotect, if I understand that right.
>>
>> poolams.c:
>> 1495 ShieldExpose(PoolArena(pool), seg);
>> 1496 clientNext =3D (*pool->format->skip)(clientRef);
>> 1497 ShieldCover(PoolArena(pool), seg);
>>
>> And when I look at ShieldExpose/Cover (am I the only one finding
>> expose/cover confusing?), I see
>
> That's explained in design/shield.txt. I think the ShieldExpose/Cover
> is intended for the collector, not for the mutator.
Thanks.
>
>>
>> shield.c:
>> 716 void (ShieldExpose)(Arena arena, Seg seg)
>> 717 {
>> 718 Shield shield;
>> 719 AccessSet mode =3D AccessREAD | AccessWRITE;
>>
>> That looks to me like
>>
>> - ANS is using barriers
>> - There is no "shield" that isn't both read and write
>>
>> As I said, I haven't read the code before, but that would make a lot of
>> sense to me, since I can't see ATM how AMS could work if it were
>> otherwise.
>
> It seems that the AMSSeg class (see DEFINE_CLASS(Seg, AMSSeg, klass))
> does not override the access method. So it seems that it does nothing on
> a read access.
>
I take your word for it. I searched for other segments that set "access"
and the only one I found was AWL. Then I got lost in code. OOP in C :-/.
I'm beginning to be seriously concerned about AMS.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 08:54:24 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 04:54:24 2025
Received: from localhost ([127.0.0.1]:60272 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6PwF-00032l-Ve
for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 04:54:24 -0400
Received: from mail-10631.protonmail.ch ([79.135.106.31]:12017)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1v6PwB-00032E-Ni
for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 04:54:22 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1759913652; x=1760172852;
bh=dkyaBecEPvFqPLZGDvdz/snhD+o+TQSTQNAUlDwxcIg=;
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;
b=R6a4sN6AIlx6f7HHDzkzisgLIk7klCCXqfuKsUuA8TlLc9DvCOLTQIjpp7wW/1RJG
VP/llg/zxSegMBVSZqPiyhDSY4YcxVo8E4L9jTAqOIV54T2BLuVAzW0jUF9iExJlcu
iwXRSHHDgyFa97b98eAnVCp9Rfct6/XyVLEZNdaXDTQpfOJBxYTn/Gpwil94HVP3S2
ALZXdiKmonehF0Cxmkx/xf5lALf0MCaNZnuK+YAyCM90ZYyVzKOvfvDmpTrJdR3iMv
EKiqGpyxXx+YLz0jCZBMQHjkG7yv6+ldfzKiKxLy8pI81fgzrvmG1dbrmuxanWTmRi
kQf4ktT9WZvCQ==
Date: Wed, 08 Oct 2025 08:54:07 +0000
To: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
Message-ID: <87ecrdepx7.fsf@HIDDEN>
In-Reply-To: <m2a5224pkr.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN>
<87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN>
<87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: cc5e9413e3f12a53df7e68922eb3a30e18646fcf
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: 79584
Cc: Helmut Eller <eller.helmut@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>,
Oliver Reiter <oliver.reiter@HIDDEN>, 79584 <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:
>
>> The way MPS works (if I understand it correctly, that is; corrections
>> welcome) is to do as little as possible when it starts a GC cycle: it
>> starts with the roots and ensures that all objects reachable from the
>> roots are either protected or have been fixed. It does not, in
>> particular, fix all mark-and-sweep segments automatically, just those
>> objects which are directly referenced by unprotected roots.
>>
>> The "directly" is important: in our case, there's a root referencing a
>> hash table which contains the global refs, but the hash table lives in a
>> protected (AMC) segment. That means MPS doesn't inspect it until it has
>> to lift that barrier, but the module goes behind our back and accesses
>> the emacs_value (a pointer to the Lisp_Object content of a pseudovector)
>> directly, using a pointer into the unprotected (AMS) segment that MPS
>> doesn't know about. So it gets unfixed data, which points to dead
>> objects.
>
> Hi Pip,
>
> Sorry, I have only skimmed over the whole thread, but from what I've
> seen, and from what you write, I wonder a bit if it could perhaps be the
> problem that I can't read. Reading the AMS pool reference again, I see
> now that it says
>
> Blocks may only be referenced by base pointers (unless they have
> in-band headers).
That's true. It's actually a bit more complicated than that: ambiguous
interior pointers are allowed (they don't cause crashes), but they don't
preserve the objects they point to (I don't understand whether that
means accessing data through them is fundamentally unsafe, or whether
it's okay to do so as long as you ensure that another reference keeps
the data alive).
> In this case, the module_global_reference pseudo-vectors live in AMS,
> and emacs_values are interior pointers.
But emacs_values live in the module's heap or data section, and MPS
doesn't know about them, so they cannot preserve data no matter what
they point to.
> Could that be related? Where did the emacs_value in your case come from?
A global variable declared by the module, in my case: elisp.c in the
vterm module declares a number of those.
However, I do think your observation means that putting cons cells in an
AMS pool would be very tricky, since those are sometimes kept alive
through a stack pointer to the CDR cell, and AMS doesn't allow for
that. Even changing the grain size doesn't work because the cdr pointer
would then be unaligned and unaligned ambiguous pointers are simply
ignored.
As the documentation states:
AMS is not currently suitable for production use.
I'm afraid that's true.
Pip
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 08:18:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 04:18:17 2025
Received: from localhost ([127.0.0.1]:60222 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6PNJ-00014Q-I3
for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 04:18:17 -0400
Received: from mail-wr1-x433.google.com ([2a00:1450:4864:20::433]:43081)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>)
id 1v6PNF-00013p-FN
for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 04:18:15 -0400
Received: by mail-wr1-x433.google.com with SMTP id
ffacd0b85a97d-3fc36b99e92so477390f8f.0
for <79584 <at> debbugs.gnu.org>; Wed, 08 Oct 2025 01:18:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1759911486; x=1760516286; 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=urRglg6T8ZQmnulkajUw2cvMxs1KcW/wqOLUrjrYofM=;
b=jDw/PkHu8m6mzT6Cax9/aZPaWOK+NpEVmXxb7ZF1T1+KLS++u5jL8oJakDKH5AXjX3
wz0ka5r6QYVv7avEJAjyB8j77z3tg4xZhIFpvWrsIRAfjGeWeTjAMWnfdefNDNQhu7cI
EcdsOwadZoq0dQjJJEyX5mc7G/3Mmc45YODfY544wq6XPz/8NqVahej7qi/+AhMOhO8B
Z39YX5BdvlDRZMsOmO4jgNDqUz69RIfmUAIE3snArSh1EiPSZ6RqSGm5NEIMwp+nDV6X
sTEFkiSX0zYU+7gYLryGgNUiHwYAEWvTWeuPp0U8ZKmKHJk/VYkMUatJRG4WvXbNugWT
pM3w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1759911486; x=1760516286;
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=urRglg6T8ZQmnulkajUw2cvMxs1KcW/wqOLUrjrYofM=;
b=n1wG3V6tBUQOnZY8ctf+OziXZyRd0ZYgSKC1c90y8T67SIZj1/bLYshV1kLSVzKczr
rlzaX7CfB4g+nW0PGk4yDZ9Sbse5l6CjhfQ7X29OCwra9rGAxhVKNs+nhXNJCubi6Qn7
3o5jqlppev4CphLWliToaerEcqDzBfkVlzkQUAUejbSM4nnTOQxgbf4XL3HmRNzfEkPu
MU+86BeDWZU4DWy3SbBh23F3yKXapHYzCRoeyX+R0fnqkCwvOy85p1QouZmiCU46k6TB
QyQRaWEx6KylaH0PjXPqsY3RuA5P1TnOtHMeCnGyuKszGazbylI0bqmwJfQywcnSzv9I
gKUw==
X-Forwarded-Encrypted: i=1;
AJvYcCUDdlzgVl8LjtFcWRHcjiGkBV3mdY9oOvxmGyBooRp486U+7l2CXAilogbKe2JOYjVRTh9DHQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwXo+g28nC+S4umFnNYtwgu6WEPSaHg1TBsaa/1HkPcZJnD+9Cl
mgR79mzlC7KnvW8ASlO56NXaQr5qtyVipRpQUCnLPJYunK1ZW+YssWg3xoZr7A==
X-Gm-Gg: ASbGncsRa//cPPA9tpazBp9saVZ02cHW7m6US7ZNu8kEE2zYc3/zxhcmhi4iqxdRBrg
TiTnZ9Ft2Fp+rT2yj7RiC8o7PeNHEdJro53efvi71Tqgl4aRpDjJQiWvFPM4DxHal2VQ0uS7zIs
3VNx8Tc8+dlz+KJKIK4OhAsbgSH30zPslmYpJ0t0pur4eVegnKZzityXTsCDoFgrT5VVDZKH3jV
qmeHLIHpljUjK2oI6k8JtKb2LBQUEepTpdYRsdF44vK2uwbY1g6mNn0kqQNLVOtuLi+/JuGnhqE
lT7YXHHuaEG5WwGM9fGrRfymyTAYvOMQIIpuHVhcghlHQerh3Qb0hXCi92oXurt0SdWIkfzSGm+
XRXqtACShh8cr1c5HZqcgYIUGiCdYAmFYd1m1lDp6U7c4
X-Google-Smtp-Source: AGHT+IEZgpNK53jguQ/srEC+z5ae2T7yRgttbleyPJ/rchQ9BrI8RuhGGZhXv1by2+rep3+ofUzB/A==
X-Received: by 2002:a5d:5005:0:b0:425:8334:9a9d with SMTP id
ffacd0b85a97d-42583349adamr2805654f8f.1.1759911486237;
Wed, 08 Oct 2025 01:18:06 -0700 (PDT)
Received: from caladan ([31.177.112.212]) by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-4255d8f02a8sm29244597f8f.39.2025.10.08.01.18.05
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 08 Oct 2025 01:18:05 -0700 (PDT)
From: Helmut Eller <eller.helmut@HIDDEN>
To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <m2jz15q2d0.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN>
<87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN>
<87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<m2o6qiowat.fsf@HIDDEN> <874is9dhj9.fsf@HIDDEN>
<m2jz15q2d0.fsf@HIDDEN>
Date: Wed, 08 Oct 2025 10:18:04 +0200
Message-ID: <87tt09bydf.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: 79584
Cc: 79584 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>,
Oliver Reiter <oliver.reiter@HIDDEN>, 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 (-)
On Wed, Oct 08 2025, Gerd M=C3=B6llmann wrote:
[...]
>
> I've read the code a bit now, and I get the feeling that the docs are
> wrong. With all caution, since I have always refused to study the MPS
> code more than absolutely necessary:
>
> In amsSegFix, I see that "shields" are used, at least in some cases.
> That should be something like mprotect, if I understand that right.
>
> poolams.c:
> 1495 ShieldExpose(PoolArena(pool), seg);
> 1496 clientNext =3D (*pool->format->skip)(clientRef);
> 1497 ShieldCover(PoolArena(pool), seg);
>
> And when I look at ShieldExpose/Cover (am I the only one finding
> expose/cover confusing?), I see
That's explained in design/shield.txt. I think the ShieldExpose/Cover
is intended for the collector, not for the mutator.
>
> shield.c:
> 716 void (ShieldExpose)(Arena arena, Seg seg)
> 717 {
> 718 Shield shield;
> 719 AccessSet mode =3D AccessREAD | AccessWRITE;
>
> That looks to me like
>
> - ANS is using barriers
> - There is no "shield" that isn't both read and write
>
> As I said, I haven't read the code before, but that would make a lot of
> sense to me, since I can't see ATM how AMS could work if it were
> otherwise.
It seems that the AMSSeg class (see DEFINE_CLASS(Seg, AMSSeg, klass))
does not override the access method. So it seems that it does nothing on
a read access.
Helmut
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 07:28:23 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 03:28:23 2025
Received: from localhost ([127.0.0.1]:60128 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v6Ob0-00064r-Lo
for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 03:28:23 -0400
Received: from mail-wm1-x332.google.com ([2a00:1450:4864:20::332]:56405)
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 1v6Oax-00064R-AX
for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 03:28:20 -0400
Received: by mail-wm1-x332.google.com with SMTP id
5b1f17b1804b1-46e4f2696bdso85031675e9.0
for <79584 <at> debbugs.gnu.org>; Wed, 08 Oct 2025 00:28:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1759908493; x=1760513293; 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=NwswFWj4v5Wgg4W/ui43SYXlmvNqZFhD0gNawbZl8LE=;
b=WlK2kt3BdSTOpducqh9n/Qibcpfb7ao6zv6zf2zL0VQIV4/a2ruKlFmZZr5RJaciQt
n5T300TK8Y+S7QuqEIvJpXKQGXawuYMIe/++qc8tfCVtaX8U9lgQPExci+k/xekaDF/k
si+DXR8Ns6WeS4MXXuAWSKthyzbaBEg90eYYAMY9W4/+SIRSrj/aM27xq1zcpS7sfrBN
HujZAnHPpN8+3ccb+FXUe2AyXo3mYX73+2w/9TcUqLlOO62xv+lJ4w774ep7zUyQuQSf
4MdYQ7vFjyenrOfkavO3Q4Jg5llZ3nzeuyXaPCd8GIiM/Xnc3ZcN07QskZiz7FPwp3YP
ByBA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1759908493; x=1760513293;
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=NwswFWj4v5Wgg4W/ui43SYXlmvNqZFhD0gNawbZl8LE=;
b=TqZYq+YMyTENXXqL9QsiUf1CTTuYXyy5w510FS5ZBSNvGLmOreH+VZ30ZT7ot9Hf9Q
O9GGwHlmmWDctwkH42NpXY0wvpQvxuMYPOKOVQH+0FF15BaegoKOZHGxVQKmdKwBwknn
Es+/rliv/Bt955Ru7eC8fN/fvOl75H36DLa0j+/8381RlF/Au+jzHOwDZ6F0JX0XAUFC
/AVGBjJ0c1pDi3vXPdxdYHkHfOmNrXCoEmsHlZWNkh4st21F7vqDJYK1pfAW62sUyZ8G
TAGcNcdhU5h7Z8x3p83k7Ba3J74JgQb4ppCbK49kKS+TlHohScl0334r+whp2SCADCAS
oi5Q==
X-Forwarded-Encrypted: i=1;
AJvYcCUKdTGGoQzyDXGNhuqzuU4t6WSafu+VXoFtQNLYYVUEitP+KLBJnKIaRAoZBnfDOUbFF9v3lw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwegpbnoDagSDgvTbd45/+r2H7Ej7CHw2Di3Iz92d6rDuo/uWXW
wwTAf3/pB+t22Vr/r1Gk9XutTzGI97QUrzS5nvamq72QleHfJjvqjvoWYOIQjw==
X-Gm-Gg: ASbGnctJDbGvDaWIRxxtLqatjmX4ZM4Fzs856MMGpbiBIS+sPEuU23Zhm0tv+JPqIxb
luAbV23+ZbCsDHg7rFHaUES0Mu5K5R3bifTcvLI96tm1cMpjOoJnNpk5mMbuegdfHrrJB10sJw1
0SyKAnSufIcuPoI9oY7GylPWgQjdlRNRaarY1ZC7Kg6Fb5lpjzYwhyEqEKLfo7T5g/tu/ifJDux
YZu97QQjVwsmRpbOISJq4wYdD7Ra/W47AjVdZPr6cYqonbCgqSdA+nBqWVf37GBksYXlH4YJvML
SiKzym4AeJ4shQZ7U7D4vh6DV5Et/KvQGGagtFgXtAghAmW3gm6lbXAoUfQ1ih8VvLqAC2n81+v
BKGuZOY8o+v27Vqh4ZS4vQHyGgRTxxzj5RuzwbBmSbbv/8n9n7aZxpamtfMoySt6d06oX8f8kEw
LuqoixVEYhkHc3De8eZnrQgf9vpIxDbVlQe5+HriiTvwRMJTVhf6T1fKw=
X-Google-Smtp-Source: AGHT+IHCr3TzUHe3c/X4m+rHUWU2MJl8Zhj00y9T4ipyxv+srXxyfsaa7MrgS6JWqTmuuvPv9fgcZA==
X-Received: by 2002:a05:600c:699b:b0:46e:43fa:2dd7 with SMTP id
5b1f17b1804b1-46fa9af35c6mr17904705e9.24.1759908492486;
Wed, 08 Oct 2025 00:28:12 -0700 (PDT)
Received: from pro4 (p200300e0b7062100157076a399046d07.dip0.t-ipconnect.de.
[2003:e0:b706:2100:1570:76a3:9904:6d07])
by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-46fa9c07a83sm27435265e9.6.2025.10.08.00.28.11
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Wed, 08 Oct 2025 00:28:12 -0700 (PDT)
From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>
To: Helmut Eller <eller.helmut@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <874is9dhj9.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN>
<87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN>
<87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN>
<m2o6qiowat.fsf@HIDDEN> <874is9dhj9.fsf@HIDDEN>
Date: Wed, 08 Oct 2025 09:28:11 +0200
Message-ID: <m2jz15q2d0.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: 79584
Cc: 79584 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>,
Oliver Reiter <oliver.reiter@HIDDEN>, 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 (-)
Helmut Eller <eller.helmut@HIDDEN> writes:
> On Wed, Oct 08 2025, Gerd M=C3=B6llmann wrote:
>
>> What I understand after reading it again this morning, your theory is
>> like this: We have some object X in AMC that gets moved to X'. We have
>> another object R in AMS that contains reference to X. Moving X does not
>> update the reference in R to X'. Is that right
>
> That's also my understanding.
>
>> What I do not understand is why you say that we are using a reference to
>> R to basically bypass the MPS (my words), so that we see X in R instead
>> of the X'.
>
> I think the problem is that the AMS has no read barriers. There should
> be write barriers on the AMS pool but maybe only until the flip. The
> AMC has read barriers after the flip, but no write barrier. Anyway,
> that's how I read the MPS paper.
I read it the same way. The AMS pool reference says
Blocks are not protected by barriers (1).
>> With the additional quirk of course, why should it be easy, that we
>> don't use a reference to R in our program, but an interior pointer into
>> R where the reference to X is stored in R.
>>
>> But that interior pointer thing left aside, wouldn't MPS not fixing the
>> X in R mean that MPS/AMS is broken in a very basic eay? The docs say AMS
>> objects can contain references to objects in other pools. If that fixing
>> doesn't work, how could that ever work?
>
> That's indeed a good question.
>
> Helmut
I've read the code a bit now, and I get the feeling that the docs are
wrong. With all caution, since I have always refused to study the MPS
code more than absolutely necessary:
In amsSegFix, I see that "shields" are used, at least in some cases.
That should be something like mprotect, if I understand that right.
poolams.c:
1495 ShieldExpose(PoolArena(pool), seg);
1496 clientNext =3D (*pool->format->skip)(clientRef);
1497 ShieldCover(PoolArena(pool), seg);
And when I look at ShieldExpose/Cover (am I the only one finding
expose/cover confusing?), I see
shield.c:
716 void (ShieldExpose)(Arena arena, Seg seg)
717 {
718 Shield shield;
719 AccessSet mode =3D AccessREAD | AccessWRITE;
That looks to me like
- ANS is using barriers
- There is no "shield" that isn't both read and write
As I said, I haven't read the code before, but that would make a lot of
sense to me, since I can't see ATM how AMS could work if it were
otherwise.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 06:39:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 02:39:02 2025 Received: from localhost ([127.0.0.1]:60063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6NpG-0003cp-IP for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 02:39:02 -0400 Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:43097) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>) id 1v6NpD-0003cI-8P for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 02:39:00 -0400 Received: by mail-wm1-x336.google.com with SMTP id 5b1f17b1804b1-46e542196c7so3112555e9.0 for <79584 <at> debbugs.gnu.org>; Tue, 07 Oct 2025 23:38:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759905533; x=1760510333; 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=BrMLtL5r9ZfU0w0uKo8KG5m8vz4FgtraLI1oqgUtVKQ=; b=IJR7lWJ0JpYYqrN8M0qrmBXLdUF6dXC8B47ZRaX2WfJWB3Lk9ua41X7Tm87C5163mA cL06AbuQItdsoykvMmF26Cwue0c7vONnjlpopptNqsMvkZZOV5h57KVrmh4lsye7IBR5 Ze51Y/+LzQQhu8bQ9rxC3jCqeXpsXmAbupZJ3KOO42NXli6p4B9ORa8tjZ7WF7xA/0Sm TuNj378+zjOzLzJlgwYtXwYX/+CYFExN59GLHsXt6QpDYw9EGAtVaCOodiViXFa/V4/O z9GH9ufPki8/IDfuHpcWGTrxsPU8J6kU4huo9xXk6X4z2K4gEMEge8mK8gHGnMKgaXcU 7D/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759905533; x=1760510333; 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=BrMLtL5r9ZfU0w0uKo8KG5m8vz4FgtraLI1oqgUtVKQ=; b=GiuYHc/YBni8PU+mEEkjm0VZWc8JeGqqzCMsDwPRY3wfRwnUyY7WXyjTiWnimIroiy Gr7lzf0Gck8J+HyQdkL8pQqYRJbOBXytN3M1VozcOk8e31FwnKPmPBYVoQqNUzaF5L3E 4NNPCRejzBS91UfjQbDYNCg2G1hmazCamWV/E1e2QOVz3hRaFTO9tOH2inzYnOpI4xBB Vwt/tOXj1SZgRhHDygUcoQLuQsl7/xwdaqDayeiPSaXI3yzu0uKfePIRBdmVp5UDN9wB fJEkNvl34emG6ZNSDibsilH8yfFf22+IbbtLqzQpmZXygASeOJT5I/+5/uD+MhyVOmA8 kDZQ== X-Forwarded-Encrypted: i=1; AJvYcCVy18hfBq2EFEp1KhXMkdxCxAv0nVykjfCvh5ByLAOZQEaT7UO6ihMg3WGcmfuoEgcozeS5fA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxkkkfhE4mzicN4Am52SFgiN9tb5XjrXsObk85kzTXSUUUMGpZc G2466MnI0rojnTVkOd81GrlNvNl6VSvanO66nMFrAYjHsqR8hoYskq7QAmgXLQ== X-Gm-Gg: ASbGnct87nnuYC5In9dwW2QojMCeckrcbRP5c5BNwlzmtc0w+AVLBrdVMe/xvEp3ikE 9h4CAXqJTA/OvYiIQ5s46rfXgSRogFOhYUL+WCADj6rnG/TaNYf7hOok8wO1JUfjqDYjxAZpNLW FsunIL8zgDAB8Txp5OELeNhJgwrxmIowL6qeAK6aSou6Q+VFAgIs86NmuqRvIgIe/nnmBLKuIUt QV7P/FmF6seYYjJ3pam9+M+DwKaEPc1vxdsfZTeXn+mEy9tRT2bDVv50gEgf7mZM4aNxys/f4j5 LXHcxosAnEsJBGAIadEiYg4FrFiWSvNLm0E803PkdrZLrHJ7m8BMCmo0ZDMJJvFkBDlbIXoMl2W 70g6/gZlJ/1gcSzOO9kxXFYEtHcLBmXygTMRxK2T32dTR X-Google-Smtp-Source: AGHT+IEljty4d5w1O7snfLWMsBrhQNngN8GRdvTGN3LIegURM874QJHsVkAOA87PoSyVlnikhYAaxg== X-Received: by 2002:a05:600c:3543:b0:458:b8b0:6338 with SMTP id 5b1f17b1804b1-46fa9e98805mr13786435e9.6.1759905532500; Tue, 07 Oct 2025 23:38:52 -0700 (PDT) Received: from caladan ([31.177.112.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-46fab3d2d65sm6986255e9.2.2025.10.07.23.38.51 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Oct 2025 23:38:52 -0700 (PDT) From: Helmut Eller <eller.helmut@HIDDEN> To: Gerd =?utf-8?Q?M=C3=B6llmann?= <gerd.moellmann@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <m2o6qiowat.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN> <87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN> <87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN> <m2o6qiowat.fsf@HIDDEN> Date: Wed, 08 Oct 2025 08:38:50 +0200 Message-ID: <874is9dhj9.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: 79584 Cc: 79584 <at> debbugs.gnu.org, Pip Cet <pipcet@HIDDEN>, Oliver Reiter <oliver.reiter@HIDDEN>, 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 (-) On Wed, Oct 08 2025, Gerd M=C3=B6llmann wrote: > What I understand after reading it again this morning, your theory is > like this: We have some object X in AMC that gets moved to X'. We have > another object R in AMS that contains reference to X. Moving X does not > update the reference in R to X'. Is that right That's also my understanding. > What I do not understand is why you say that we are using a reference to > R to basically bypass the MPS (my words), so that we see X in R instead > of the X'. I think the problem is that the AMS has no read barriers. There should be write barriers on the AMS pool but maybe only until the flip. The AMC has read barriers after the flip, but no write barrier. Anyway, that's how I read the MPS paper. > With the additional quirk of course, why should it be easy, that we > don't use a reference to R in our program, but an interior pointer into > R where the reference to X is stored in R. > > But that interior pointer thing left aside, wouldn't MPS not fixing the > X in R mean that MPS/AMS is broken in a very basic eay? The docs say AMS > objects can contain references to objects in other pools. If that fixing > doesn't work, how could that ever work? That's indeed a good question. Helmut
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 8 Oct 2025 04:24:47 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Oct 08 00:24:47 2025 Received: from localhost ([127.0.0.1]:59882 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6LjK-0004G2-Cw for submit <at> debbugs.gnu.org; Wed, 08 Oct 2025 00:24:46 -0400 Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:47210) 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 1v6Lj9-0004FU-9u for 79584 <at> debbugs.gnu.org; Wed, 08 Oct 2025 00:24:42 -0400 Received: by mail-wr1-x429.google.com with SMTP id ffacd0b85a97d-3ed20bdfdffso6134006f8f.2 for <79584 <at> debbugs.gnu.org>; Tue, 07 Oct 2025 21:24:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759897469; x=1760502269; 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=UC/HREvzg0VOh+YsAYVDepE/5C8g7MIBMDp1mTBnDfc=; b=CRhOxxTrTlm/qheZ15KIzqJaNVIvdOdFc3l/byqP64K0y5Mopyvzqo0PzgwXVrmy3e l8vt8z/59lnAmNGtOafPUG985LlTzMQUiOxAUDXwBg+F6WiCwXghK8miJmPCwdTctUdA LLH+FcAlBQ4FIkbOiXKQQeTXMZT65B5K9HFryPJzJFqi6VWgUJ4vF1Sw9zrFP0wUkQAI 8zol3DjY8ZmuU/zqsWLYJXnPRpsqVnD9AzGWrWzZCaxrCp7GoXC8t+higedmW2Dk1Esg U9YPpfspCoaPe7qky/ADYSYD+QSXsg6ru5CsGrxKRnZ7f8juhU7iNlyVd7KvGE09OnYA SMVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759897469; x=1760502269; 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=UC/HREvzg0VOh+YsAYVDepE/5C8g7MIBMDp1mTBnDfc=; b=p7Coo1Jt7IiMsLyVx8eaofBe8YWh+YN/J23UhFWzOqtkd/n7aNwxbTKCdZzFPH4BNL DiiTfx15FMLQiwyVbvcFZzGVogUM0CzJkiC8vIa8pzM77/yQu23nnjGNyfTzqpK9lG1S bEii4E1P7dXT4bmpyOVjI6el4S9XUE+kT4Y/PVk4CgFIK54bFGzi9pCkgI10ZVdw5dp1 0uNSPTVuGedyIIVviNZUkZGZptakqX8B0PJAVGAzwf1IHVy7n/YrWA6QQh8yBtP75VQt rC0w8LOD6fkHUGdDwO2bcY9A4zqUMOpauKLoxh0wfvv7ArDLawdSa21hU9ahdNRjvzA5 D/NQ== X-Forwarded-Encrypted: i=1; AJvYcCUAHtswQ8prOKeUYfd+aTQ1k6aL43Jz3waaNLQ7lTGXHiOy3DiCEFrcZcI+LehhE87zqeL2RQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwSN+pJepA5ZWhrmTuub0zgZ8KPjxOK4zIKqPcWGyRkBbnrDZZ5 s3//2tpN5uLE1DhlgZtxv3lDY3x1frqFIMTnc9i7+HPDTeoRtf1fvXFQ X-Gm-Gg: ASbGncv3NAe6LmbIXLKPNS/9bbMFXvEvS+FA0a7IqHvgVbh0eiim8C/+P1RaYXm/y5W mQoWVcPKKayxxxHsDVwx7g0KwnTCMkBxLfUfycKuZNjrmvgJZ3SSPXFF3Bh0OYPV//TgXtkpKHV rX/UAzY1ooFiiyBi+ct813NKsPOqqqw6PTrR9Byk5sEFHmxLEQITIv2j+kw8nIZ2fDNi4QgFLb9 UmgxKc9ZSf13e0UObU8Laqqx9hcZYIl1fGjyfuyxT1JOPBHCMULbyT3lNECK56puXCgy4Z2gO3p 2vk8vwcW//uV6y0+I2bVofVapjoIM51QeTTi8AINGkfimqTVEHyvdxO1gJD7mg7sKWuko/zI2r8 GpeBFj0WSSfxVV9iKoeRpZV1lm7igKTUDRo2F5szapixg58dqgK6TbSjdpvfBGNOgWIUlj81l2m KqpTwnlBHlaafUpz0x7U/mPSJdUpc17YcltrC1VtN8nZ6yafOpM2FH1XAcRPO9J5DkdA== X-Google-Smtp-Source: AGHT+IEs01MTLa5VWCNz+fNPvB8ZWwS6gkTwXsixd41z0ByvF+FItNZTvlUKNP4hFO6BiJ3C9CoM+w== X-Received: by 2002:a05:6000:40da:b0:403:8cc:db6b with SMTP id ffacd0b85a97d-4266e7d93b4mr944208f8f.35.1759897468722; Tue, 07 Oct 2025 21:24:28 -0700 (PDT) Received: from pro4 (p200300e0b7062100157076a399046d07.dip0.t-ipconnect.de. [2003:e0:b706:2100:1570:76a3:9904:6d07]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4255d8ab8fdsm27631673f8f.15.2025.10.07.21.24.26 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Oct 2025 21:24:27 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <m2a5224pkr.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN> <87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN> <87ms62ency.fsf@HIDDEN> <m2a5224pkr.fsf@HIDDEN> Date: Wed, 08 Oct 2025 06:24:26 +0200 Message-ID: <m2o6qiowat.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: 79584 Cc: Helmut Eller <eller.helmut@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Oliver Reiter <oliver.reiter@HIDDEN>, 79584 <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: > >> The way MPS works (if I understand it correctly, that is; corrections >> welcome) is to do as little as possible when it starts a GC cycle: it >> starts with the roots and ensures that all objects reachable from the >> roots are either protected or have been fixed. It does not, in >> particular, fix all mark-and-sweep segments automatically, just those >> objects which are directly referenced by unprotected roots. >> >> The "directly" is important: in our case, there's a root referencing a >> hash table which contains the global refs, but the hash table lives in a >> protected (AMC) segment. That means MPS doesn't inspect it until it has >> to lift that barrier, but the module goes behind our back and accesses >> the emacs_value (a pointer to the Lisp_Object content of a pseudovector) >> directly, using a pointer into the unprotected (AMS) segment that MPS >> doesn't know about. So it gets unfixed data, which points to dead >> objects. > > Hi Pip,=20 > > Sorry, I have only skimmed over the whole thread, but from what I've > seen, and from what you write, I wonder a bit if it could perhaps be the > problem that I can't read. Reading the AMS pool reference again, I see > now that it says > > Blocks may only be referenced by base pointers (unless they have > in-band headers). > > In this case, the module_global_reference pseudo-vectors live in AMS, > and emacs_values are interior pointers. > > Could that be related? Where did the emacs_value in your case come from? What I understand after reading it again this morning, your theory is like this: We have some object X in AMC that gets moved to X'. We have another object R in AMS that contains reference to X. Moving X does not update the reference in R to X'. Is that right What I do not understand is why you say that we are using a reference to R to basically bypass the MPS (my words), so that we see X in R instead of the X'. With the additional quirk of course, why should it be easy, that we don't use a reference to R in our program, but an interior pointer into R where the reference to X is stored in R. But that interior pointer thing left aside, wouldn't MPS not fixing the X in R mean that MPS/AMS is broken in a very basic eay? The docs say AMS objects can contain references to objects in other pools. If that fixing doesn't work, how could that ever work? Don't know, maybe I'm confusing myself. Anyway, I don't yet get it.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 7 Oct 2025 18:58:57 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 07 14:58:57 2025 Received: from localhost ([127.0.0.1]:59060 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6Ctl-0001EP-3G for submit <at> debbugs.gnu.org; Tue, 07 Oct 2025 14:58:57 -0400 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:45406) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>) id 1v6Cth-0001E8-QJ for 79584 <at> debbugs.gnu.org; Tue, 07 Oct 2025 14:58:54 -0400 Received: by mail-wr1-x42b.google.com with SMTP id ffacd0b85a97d-3f44000626bso4315020f8f.3 for <79584 <at> debbugs.gnu.org>; Tue, 07 Oct 2025 11:58:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759863527; x=1760468327; 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=nm+iIT+qP0PqulKlX5q31MnYewZtbkL8YB/m1OJc6ZA=; b=Wv1FTYQBL8o3fbFOsjFmRMprMTPMyPJJsJjU8j7xN8xtVDNGFUpjc48uu55o8QoN9n 91uhtkuAepxxPP40bHwOE8fXgOINpEqnvinkB6vGfRHOYlvLiCy3jzQh8PcLhkajCx6p Ez+302tH9XjmXc8KDg32gWYsZMXM4e9TFdYLfcZ0MBMq33dJyK9HmejYLb1vuDQiwdZM ILUj7FI1vHvQdUGjZoXqSAIfxH8h5IYMTMvB2ZX28DX+Sj7YP3EilM6qRKs9Vqzbse82 qILTZ0GQPeGMf91x3RDFKMZTe7L7KW8O3IWdgwnes0o/X5UJIk0maXlTxS4TgUXd8uhX WTsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759863527; x=1760468327; 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=nm+iIT+qP0PqulKlX5q31MnYewZtbkL8YB/m1OJc6ZA=; b=K5PFdVDQPKbqGh4lKFON4mE7E7Atdyah6GALKP1eTkJBOWfeMXlpOOlz6l5Zs7rj+a STo6PSK030/U+tt2nP//hblGqIpHLid6Di5sZIAil0PX2LL+VyZcuaNjs8TMhFijkux0 e/YImk8JzbD9V7FCKZApIj1fZfvBssmWR2fTNIBQkTo5kKYApz9hDWyReXwGpqL8fKTb V1T/2Cjsoq53T6bDBhsEF1OuMaN/gL3HW04k7lfa4lan9cevFtHbR9FF4wvrRjDJO1qc CtEoOat5sJ24W5N3vvE08hWGw4AoqousnMlVl4df4ZI4UcZ8mxVdiHm86ZsNR9QDO5Xa OFiQ== X-Forwarded-Encrypted: i=1; AJvYcCXsRDBip7WZYfFG7hX2zGvUx86A4aGMIpiAjxbK+f6m/+CSI1rfZtJ3TnS19BJjjWF53bDHmA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyHUSZd8siNylMhoRRsaKYYURgRYBXSq1J264QorTVo93RVzUwh CifKoorlhjongKt5E/U5I2yrRGm65vMrYhOOG4mU+vXXf5k+VyObku6g X-Gm-Gg: ASbGncsXtWQW6fhQdYQVqAuOadnpdAsukfcBqRW5VOozVN+rolBePpcDm3MCRSt8QFW HcEPEHepL2Xe6zkAQ+GrRcqZzMDUp83o4lxB6V7oNB7PXzAw758L0d1jrNOxKyXJW3w/q6NtaZh KChPloVhEMaIxCSmUaVPQ4evs3ARG/B7+YEnHp2VZyIsYoqztHQJn2mitNxjZpfoxMLs698pdXw FhN2l/yrObP2BAUE+AU44twDKTRmbOWpZppvuixQcRuYDhxBAgZ9hUPLcqy9Tu+UY1uj3bkIlaV y57/7CenS7xJ0tZV0nvw2bcWytbrav3eFL2rVahTFAB349rlZEarWOHseHSdXVaPx4c/uQNTuGi SEoHVyTogjkAjF1b+KlzGkfVdcwiUxoH0Q7yGHHxAk+zN X-Google-Smtp-Source: AGHT+IGgJSQSm7x7u/2mO3k2Jn1p8mpP2/2EclBrCNVkDjASL2U4w2UU4inzMgdYsSkt4fPWHdsb6Q== X-Received: by 2002:a5d:64e7:0:b0:3ee:b126:6bd with SMTP id ffacd0b85a97d-4266e8db354mr256335f8f.50.1759863527029; Tue, 07 Oct 2025 11:58:47 -0700 (PDT) Received: from caladan ([31.177.112.212]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-46fa9c07cbasm5391315e9.7.2025.10.07.11.58.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Oct 2025 11:58:46 -0700 (PDT) From: Helmut Eller <eller.helmut@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <87ms62ency.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN> <87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN> <87ms62ency.fsf@HIDDEN> Date: Tue, 07 Oct 2025 20:58:45 +0200 Message-ID: <87ikgqczdm.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: 79584 Cc: Gerd =?utf-8?Q?M?= =?utf-8?Q?=C3=B6llmann?= <gerd.moellmann@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Oliver Reiter <oliver.reiter@HIDDEN>, 79584 <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 Tue, Oct 07 2025, Pip Cet wrote: [...] > I've finally been able to reproduce this (thanks again for the reports, > and for providing the right compilation options), and I believe I > understand what's happening now. Do you have reproducible test? > The summary is that module global refs need to be roots. > > It's not sufficient for them to be accessible from roots through > MPS-managed objects, it's necessary for them only ever to be accessed > through MPS-managed objects which have been reached from roots. > > The way MPS works (if I understand it correctly, that is; corrections > welcome) is to do as little as possible when it starts a GC cycle: it > starts with the roots and ensures that all objects reachable from the > roots are either protected or have been fixed. It does not, in > particular, fix all mark-and-sweep segments automatically, just those > objects which are directly referenced by unprotected roots. > > The "directly" is important: in our case, there's a root referencing a > hash table which contains the global refs, but the hash table lives in a > protected (AMC) segment. That means MPS doesn't inspect it until it has > to lift that barrier, but the module goes behind our back and accesses > the emacs_value (a pointer to the Lisp_Object content of a pseudovector) > directly, using a pointer into the unprotected (AMS) segment that MPS > doesn't know about. So it gets unfixed data, which points to dead > objects. > > Note that there is no question of memory leaking: module global refs are > put into a strong hash table, and only removed from it when their > refcount reaches zero. Making them roots doesn't change anything about > that: we just have to destroy the root when freeing them. (In theory, we > could get rid of the hash table entirely, but I think it's a good way to > find leaked module global refs). > > I don't think that this is the right fix in the long term: global refs > are supposed to be relatively cheap, and MPS keeps roots in a linear > list, which means that they're not. However, it's better to apply this > than to crash. > > An alternative approach would be to redefine emacs_value to be a hash > table key, probably a fixnum, which is used to find the global reference > in an additional ordinary hash table. That would mean that the hash > table vector would benefit from proper protection; it'd slow down > modules very slightly, but it'd speed up the important case where a > module creates many references but isn't actively using them. This is quite tricky. It seems that the problem can only happen if the module_global_reference is accessed while a trace is in progress. So a simple igc--collect can't be used to trigger the problem. Helmut
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 7 Oct 2025 16:57:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 07 12:57:52 2025 Received: from localhost ([127.0.0.1]:58841 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6B0a-0002f0-0l for submit <at> debbugs.gnu.org; Tue, 07 Oct 2025 12:57:52 -0400 Received: from mail-ej1-x62c.google.com ([2a00:1450:4864:20::62c]:54609) 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 1v6B0X-0002el-5p for 79584 <at> debbugs.gnu.org; Tue, 07 Oct 2025 12:57:50 -0400 Received: by mail-ej1-x62c.google.com with SMTP id a640c23a62f3a-b50645ecfbbso99971966b.1 for <79584 <at> debbugs.gnu.org>; Tue, 07 Oct 2025 09:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1759856262; x=1760461062; 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=Qicf3xXpasUdWeenagzCmigqR4+I/5gHZ438fTVhaLQ=; b=SeHf38dImqKhjTUbG13VKNZPnAJt3jnykiMwwGcds/4EE/01K8JryIKv5HpA0eWkt+ oKVRdUFUq6YqINSu+euyX0Y1TcXdSXejkkVExO0BzQFE1IlprzldQiYvYHSTOCebFy6Q N22PxSEpSVDR82b0Mr4u3vacp31QPAwE0+38CGiFsVxRd8v+z8dVNEuJqSvqRRRXyZ80 c9rqVTJV3ar9MHEE8hh8DWvWZ8iW4fU1MWs5MVD91VTGvkScrkICm/RxLtHX0iFJTDPK pOClahVLAxYt1SIFwEr+K5AD5p+2VqG9wNErUMXczQ9iOEHMxQbA5SgKiJ9kPQzhyX6g 9r4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1759856262; x=1760461062; 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=Qicf3xXpasUdWeenagzCmigqR4+I/5gHZ438fTVhaLQ=; b=jjiPHU7j/mEREgsEDT/51jWRdnKDBP7OnxOz/ZuzczSzfd9wsOVXemgzuWoKHuwUqU iZlMhnjPUQxMvz4KQDusS8D9Qm7XOGmDKTSVjSmYrabkvnERMjoPZJJpEN8Np8Ru6Yjl ToOzmaIzYIFAC7odM5x8aB6yUcjDMZzs2CRI+s/dFSTGghnH8F1pwwwkr2WGt4EHPYnt 6kLrJqryY8TFcRJwZthQnSkotbGqkCY4mXlBkQdazj6/VLqrYV8Bw18I9EEx2oqA9t0A ZqVVj0DSF8+lr8UCGZEimufsMfLzT6MZQcm3/ZIJUKQauSWaiPsT8p8u4uvb41UYPYQZ FR4Q== X-Forwarded-Encrypted: i=1; AJvYcCV7V5Pw4TFi3hDfhTTXmzZvZa2lY5uMnEfG/MWTm+JZPunOHBv3WYNDh4LLqCkkx2lALgSCSA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxPrJfFkWhxb18OXIVRQ7yVOuxHfzQ9iX629HJCM6UxiLnISTh6 0U5cUBkdY5umCujK0cySzRgx1s15KrmU8EKYUlPUiP8PmmRvgpdiwOQA X-Gm-Gg: ASbGnctEcEjVhu5H3pk64HnCrfvhsK+DiZXaYznESV0l6b+UUKTd0uMzbu+D/s7Fapx f9P9w6TWOaaSXqrSJcGvMF1qbApes2dvd3x5eYiswWNHq7drKZe24NB7WDGEUERxisgHwHmlxav AeqKnoZZAvLtTgY1EV6sAbZuJtPT/OxrIexiRDb9HMQSRirIj4E4hDDWhRFMB3Af+ODB4wivQnr rpbGo+y5k/mqB0JeNOTMC8eokeHtwqfb/vWfLQ458YbJsbk3w7+3Tyuj8+RUS2r43eOhK1x40JS SHb6tRe8UihALI9P0BpHW6SES1EhOX4wPjMpK70HGjVHFB0JQeSWusm6o08lfi1etmKCgbYYpbh AERIXQO46T0FkWvYca902qKk/UXeh2ZOmtUEM/GX1qvlfH1cCRkOiB32SDXPcdpOQ16ztckLfgc jxvQUGZtsBIzbv4WNgx0s62CZLo8hSjoVpPViV/lIFCPYFPfeSwK/E0qw= X-Google-Smtp-Source: AGHT+IEDweXZIXNy6iBU8LySkJdZTDYv+xaqIb2laKIcTVYtjkIHYJqVKOu/IJ0l+LpeAiuWec67WQ== X-Received: by 2002:a17:907:a089:b0:b3a:b949:3059 with SMTP id a640c23a62f3a-b50aa48c4b9mr43778666b.18.1759856262037; Tue, 07 Oct 2025 09:57:42 -0700 (PDT) Received: from pro4 (p200300e0b72cf400bd4e96c54bee80d5.dip0.t-ipconnect.de. [2003:e0:b72c:f400:bd4e:96c5:4bee:80d5]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6376b3aa9f1sm12664131a12.8.2025.10.07.09.57.41 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 07 Oct 2025 09:57:41 -0700 (PDT) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN> To: Pip Cet <pipcet@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <87ms62ency.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN> <87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN> <87ms62ency.fsf@HIDDEN> Date: Tue, 07 Oct 2025 18:57:40 +0200 Message-ID: <m2a5224pkr.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: 79584 Cc: Helmut Eller <eller.helmut@HIDDEN>, Eli Zaretskii <eliz@HIDDEN>, Oliver Reiter <oliver.reiter@HIDDEN>, 79584 <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: > The way MPS works (if I understand it correctly, that is; corrections > welcome) is to do as little as possible when it starts a GC cycle: it > starts with the roots and ensures that all objects reachable from the > roots are either protected or have been fixed. It does not, in > particular, fix all mark-and-sweep segments automatically, just those > objects which are directly referenced by unprotected roots. > > The "directly" is important: in our case, there's a root referencing a > hash table which contains the global refs, but the hash table lives in a > protected (AMC) segment. That means MPS doesn't inspect it until it has > to lift that barrier, but the module goes behind our back and accesses > the emacs_value (a pointer to the Lisp_Object content of a pseudovector) > directly, using a pointer into the unprotected (AMS) segment that MPS > doesn't know about. So it gets unfixed data, which points to dead > objects. Hi Pip, Sorry, I have only skimmed over the whole thread, but from what I've seen, and from what you write, I wonder a bit if it could perhaps be the problem that I can't read. Reading the AMS pool reference again, I see now that it says Blocks may only be referenced by base pointers (unless they have in-band headers). In this case, the module_global_reference pseudo-vectors live in AMS, and emacs_values are interior pointers. Could that be related? Where did the emacs_value in your case come from?
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 7 Oct 2025 16:11:03 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 07 12:11:03 2025 Received: from localhost ([127.0.0.1]:58718 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v6AHG-0008Cd-K1 for submit <at> debbugs.gnu.org; Tue, 07 Oct 2025 12:11:02 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48534) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1v6AHB-0008CC-98 for 79584 <at> debbugs.gnu.org; Tue, 07 Oct 2025 12:10:59 -0400 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 1v6AH4-0000oZ-Sf; Tue, 07 Oct 2025 12:10:50 -0400 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=Yd2NdZ8KNj3XcDEmm05jA2FU1yCc1HoTgcWKSiISO/w=; b=fkEROSeE+SG9mBpkSphV +zPnhdLCs0Mvst/Oshq929HiYKI+IqjO0bF45fsfq7K4ocIW6sU1wkwZya06saDTmIEgZK30NGm4P ztQpYVG2bKnkNeIdQj+mGjimw5OcaF4HmPoXvHLg1WVsq6PS/dkL+YDxYeNHMCiJWny3mMX9GIWHz SbiA59G8olaWUzhytqYawn+07CReGfwUgrtKN15KIdX0zFOOashs8G9PeYwvKtwzxwrMHgLSBwEVT mMM1n6pI3W39yzauDx9LT7eD1g8d2XZqJWOwZH5q18TI3tvPKquXgl5JyyxCCVHjplDY3EvBi35yk GCmW5BDkpolZHA==; Date: Tue, 07 Oct 2025 19:10:46 +0300 Message-Id: <86zfa2bsl5.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Pip Cet <pipcet@HIDDEN> In-Reply-To: <87ms62ency.fsf@HIDDEN> (message from Pip Cet on Tue, 07 Oct 2025 15:37:11 +0000) Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN> <87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN> <87ms62ency.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: 79584 Cc: gerd.moellmann@HIDDEN, eller.helmut@HIDDEN, 79584 <at> debbugs.gnu.org, oliver.reiter@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: -3.3 (---) > Date: Tue, 07 Oct 2025 15:37:11 +0000 > From: Pip Cet <pipcet@HIDDEN> > Cc: Oliver Reiter <oliver.reiter@HIDDEN>, 79584 <at> debbugs.gnu.org, Helmut Eller <eller.helmut@HIDDEN>, Gerd Möllmann <gerd.moellmann@HIDDEN> > > An alternative approach would be to redefine emacs_value to be a hash > table key, probably a fixnum, which is used to find the global reference > in an additional ordinary hash table. That would mean that the hash > table vector would benefit from proper protection; it'd slow down > modules very slightly, but it'd speed up the important case where a > module creates many references but isn't actively using them. I'd indeed favor this alternative, of making emacs_value a better-behaving citizen in the IGC world. Thanks.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 7 Oct 2025 15:37:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 07 11:37:34 2025
Received: from localhost ([127.0.0.1]:58660 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v69kr-0006gK-5p
for submit <at> debbugs.gnu.org; Tue, 07 Oct 2025 11:37:34 -0400
Received: from mail-24418.protonmail.ch ([109.224.244.18]:42271)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1v69kf-0006fr-PO
for 79584 <at> debbugs.gnu.org; Tue, 07 Oct 2025 11:37:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1759851435; x=1760110635;
bh=JwoTDqXnjtgmnhMij4YTWeqBoUmYKpveb3e3SeU4ol8=;
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;
b=WQGb1f0vl3kfkhSGm8BCFcXnWO9xem3aCbyQaqv/SqGIDpBBEm4ZcwbQw1kVS2Tqp
08flgbKHhRVM+84OHGhaoDhAVhQbw86wcB5Ad/kFX+l0KWrjDwc0bSovawrbR7rGK1
0UHY525rMD1V3e6OcWgCP/zMvqarMbH1SkTbYpaqaCLXmzeCYz1T5XcuQ87fGe3KBS
rrnrxAQzFz88LMilWfAzHGG8IH06QktZMZkZn1qTJa1UC/f5H51d3xys5Ge5knU0FL
vERrwVJD2R5/FA4H2ZlwY4i/Gt7QU31YXdWialXfRFN+4LdPVu5x+SQ3dWv9kJkZ1I
Z3cz+hOkshsUA==
Date: Tue, 07 Oct 2025 15:37:11 +0000
To: Eli Zaretskii <eliz@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
Message-ID: <87ms62ency.fsf@HIDDEN>
In-Reply-To: <86jz17cku0.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN>
<87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: 25399735f315396f32289d1d83d6605e3bb341ad
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: 79584
Cc: =?utf-8?Q?Gerd_M=C3=B6llmann?= <gerd.moellmann@HIDDEN>,
Helmut Eller <eller.helmut@HIDDEN>, 79584 <at> debbugs.gnu.org,
Oliver Reiter <oliver.reiter@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 (-)
"Eli Zaretskii" <eliz@HIDDEN> writes:
>> From: Oliver Reiter <oliver.reiter@HIDDEN>
>> Cc: 79584 <at> debbugs.gnu.org
>> Date: Mon, 06 Oct 2025 20:38:12 +0200
>>
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>
>> >> Date: Mon, 06 Oct 2025 14:04:47 +0200
>> >> From: Oliver Reiter via "Bug reports for GNU Emacs,
>> >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>> >>
>> >> #15 0x00007ffff187627b in F74696d65722d6576656e742d68616e646c6572_tim=
er_event_handler_0 ()
>> >> from /home/reitero/build/sources/emacs/emacs_debug/src/../native-l=
isp/31.0.50-7aaa0ab0/preloaded/timer-3ee7cfd9-6ab3799c.eln
>> >
>> > Looks like a timer function wanted to print some message, and bumped
>> > into an invalid Lisp string or something?
>> >
>> > What does this produce:
>> >
>> > (gdb) frame 14
>> > (gdb) p args[0]
>> > (gdb) xtype
>> > (gdb) p args[1]
>> > (gdb) xtype
>> > (gdb) p args[2]
>> > (gdb) xtype
>> >
>> > For each type that the "xtype" command can print, we have a
>> > corresponding "xFOO" command, like "xstring" for Lisp strings,
>> > "xsymbol" for symbols, etc. So please use those immediately after
>> > each "xtype" to show the 3 arguments of that funcall. (I expect
>> > args[0] to be the symbol format-message and args[1] to be a format
>> > string.)
>>
>> You guessed very good:
>>
>> (gdb) frame 14
>> #14 0x0000555555703c3f in Ffuncall (nargs=3D3, args=3D0x7fffffffcda0) at=
/home/reitero/build/sources/emacs/emacs_debug/src/eval.c:3218
>> 3218=09 Lisp_Object val =3D funcall_general (args[0], nargs - 1, args + =
1);
>> (gdb) p args[0]
>> $1 =3D XIL(0x2aaa8c3dee70)
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $2 =3D (struct Lisp_Symbol *) 0x7fffe1d0ae50
>> "format-message"
>> (gdb) p args[1]
>> $3 =3D XIL(0x7fffe1d68044)
>> (gdb) xtype
>> Lisp_String
>> (gdb) xstring
>> $4 =3D (struct Lisp_String *) 0x7fffe1d68040
>> " `%s'"
>> (gdb) p args[2]
>> $5 =3D XIL(0x2aaa8d087080)
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $6 =3D (struct Lisp_Symbol *) 0x7fffe29b3060
>> 0
>
> So the symbol is bogus? What does the below show?
>
> (gdb) p *((struct Lisp_Symbol *) 0x7fffe29b3060)
I've finally been able to reproduce this (thanks again for the reports,
and for providing the right compilation options), and I believe I
understand what's happening now.
The summary is that module global refs need to be roots.
It's not sufficient for them to be accessible from roots through
MPS-managed objects, it's necessary for them only ever to be accessed
through MPS-managed objects which have been reached from roots.
The way MPS works (if I understand it correctly, that is; corrections
welcome) is to do as little as possible when it starts a GC cycle: it
starts with the roots and ensures that all objects reachable from the
roots are either protected or have been fixed. It does not, in
particular, fix all mark-and-sweep segments automatically, just those
objects which are directly referenced by unprotected roots.
The "directly" is important: in our case, there's a root referencing a
hash table which contains the global refs, but the hash table lives in a
protected (AMC) segment. That means MPS doesn't inspect it until it has
to lift that barrier, but the module goes behind our back and accesses
the emacs_value (a pointer to the Lisp_Object content of a pseudovector)
directly, using a pointer into the unprotected (AMS) segment that MPS
doesn't know about. So it gets unfixed data, which points to dead
objects.
Note that there is no question of memory leaking: module global refs are
put into a strong hash table, and only removed from it when their
refcount reaches zero. Making them roots doesn't change anything about
that: we just have to destroy the root when freeing them. (In theory, we
could get rid of the hash table entirely, but I think it's a good way to
find leaked module global refs).
I don't think that this is the right fix in the long term: global refs
are supposed to be relatively cheap, and MPS keeps roots in a linear
list, which means that they're not. However, it's better to apply this
than to crash.
An alternative approach would be to redefine emacs_value to be a hash
table key, probably a fixnum, which is used to find the global reference
in an additional ordinary hash table. That would mean that the hash
table vector would benefit from proper protection; it'd slow down
modules very slightly, but it'd speed up the important case where a
module creates many references but isn't actively using them.
From ab5c161e4c2d398bd1d0bf21b0f2fde983021748 Mon Sep 17 00:00:00 2001
From: Pip Cet <pipcet@HIDDEN>
Date: Tue, 7 Oct 2025 15:09:10 +0000
Subject: [PATCH] Turn module global references into roots (bug#79584)
* src/igc.c (igc_alloc_global_ref): Allocate root.
(igc_free_global_ref): New function.
* src/emacs-module.c (module_free_global_ref) [MPS]: Call it.
---
src/emacs-module.c | 3 +++
src/igc.c | 19 +++++++++++++++----
src/igc.h | 3 +++
3 files changed, 21 insertions(+), 4 deletions(-)
diff --git a/src/emacs-module.c b/src/emacs-module.c
index f3a92500f62..f5b30935050 100644
--- a/src/emacs-module.c
+++ b/src/emacs-module.c
@@ -472,6 +472,9 @@ module_free_global_ref (emacs_env *env, emacs_value glo=
bal_value)
eassert (0 < ref->refcount);
if (--ref->refcount =3D=3D 0)
hash_remove_from_table (h, obj);
+#ifdef HAVE_MPS
+ igc_free_global_ref (ref);
+#endif
}
=20
MODULE_INTERNAL_CLEANUP ();
diff --git a/src/igc.c b/src/igc.c
index 438aee08520..ed2561afe2b 100644
--- a/src/igc.c
+++ b/src/igc.c
@@ -4304,11 +4304,22 @@ alloc_immovable (size_t size, enum igc_obj_type typ=
e)
igc_alloc_global_ref (void)
{
size_t nwords_mem =3D VECSIZE (struct module_global_reference);
- struct Lisp_Vector *v
- =3D alloc_immovable (header_size + nwords_mem * word_size, IGC_OBJ_VEC=
TOR);
- XSETPVECTYPESIZE (v, PVEC_MODULE_GLOBAL_REFERENCE, 0, nwords_mem);
- return v;
+ struct module_global_reference *ref
+ =3D xzalloc (sizeof *ref);
+ ref->value.v =3D Qnil;
+ root_create_exact (global_igc, &ref->value.v, &ref->value.v + 1,
+=09=09 scan_exact, "module global ref");
+ XSETPVECTYPESIZE (ref, PVEC_MODULE_GLOBAL_REFERENCE, 0, nwords_mem);
+ return ref;
}
+
+void
+igc_free_global_ref (struct module_global_reference *ref)
+{
+ igc_destroy_root_with_start (ref);
+ xfree (ref);
+}
+
#endif
=20
Lisp_Object
diff --git a/src/igc.h b/src/igc.h
index 13b5646f387..36d4d99b9b7 100644
--- a/src/igc.h
+++ b/src/igc.h
@@ -80,7 +80,10 @@ #define EMACS_IGC_H
void igc_remove_all_markers (struct buffer *b);
void igc_resurrect_markers (struct buffer *b);
Lisp_Object igc_alloc_symbol (void);
+#ifdef HAVE_MODULES
void *igc_alloc_global_ref (void);
+void igc_free_global_ref (struct module_global_reference *ref);
+#endif
=20
struct Lisp_Buffer_Local_Value *igc_alloc_blv (void);
void *igc_alloc_handler (void);
--=20
2.50.0
Pip
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 7 Oct 2025 07:37:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 07 03:37:37 2025
Received: from localhost ([127.0.0.1]:56602 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v62GO-0002jU-Rh
for submit <at> debbugs.gnu.org; Tue, 07 Oct 2025 03:37:37 -0400
Received: from mail.snapdragon.cc ([51.79.228.117]:51628)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <oliver.reiter@HIDDEN>)
id 1v62GN-0002jF-6B
for 79584 <at> debbugs.gnu.org; Tue, 07 Oct 2025 03:37:35 -0400
From: Oliver Reiter <oliver.reiter@HIDDEN>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snapdragon.cc;
s=default; t=1759822652;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=r1tv2lM2/Mohf2HOJX74Kxvmf/7kl06Nf9f/iIDQQyo=;
b=PbTi8ybG+w1XEeuqJpMK2WmZhRLaW2vah2tYcoiNiZDuP9DaZ2jPg5QhCMP1j44KGTulfa
Pbw83DFQoes6NYZwCgGePao7Iyv0iziVJvd5DXzDpSvpC0Iw+iQk7vO+AyOK2m8rslABGg
pjqMDkPuZggtoHE70myIZ0VROiNZLVo=
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <86ikgrckp1.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <87v7ksdmv5.fsf@HIDDEN>
<87ikgrzx7x.fsf@HIDDEN> <86ikgrckp1.fsf@HIDDEN>
Date: Tue, 07 Oct 2025 09:37:28 +0200
Message-ID: <87qzvf6u2v.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79584
Cc: pipcet@HIDDEN, 79584 <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
Content-Disposition: inline
Eli Zaretskii <eliz@HIDDEN> writes:
>> Cc: 79584 <at> debbugs.gnu.org
>> Date: Mon, 06 Oct 2025 20:44:34 +0200
>> From: Oliver Reiter via "Bug reports for GNU Emacs,
>> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>>
>> (gdb) p *XOBARRAY(Vobarray)
>> No symbol "Vobarray" in current context.
>
> Another problem with macros? How about this:
>
> (gdb) p *XOBARRAY(globals.f_Vobarray)
(gdb) p *XOBARRAY(globals.f_Vobarray)
$11 = {
header = {
gc_header = {
v = 17179870497,
gcaligned = 33 '!'
},
size = 4611686018695831552
},
buckets = 0x7fffe6825010,
size_bits = 17,
count = 103537
}
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 7 Oct 2025 07:36:32 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 07 03:36:32 2025
Received: from localhost ([127.0.0.1]:56598 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v62FM-0002h3-6p
for submit <at> debbugs.gnu.org; Tue, 07 Oct 2025 03:36:32 -0400
Received: from mail.snapdragon.cc ([2402:1f00:8001:f75::2]:46760)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <oliver.reiter@HIDDEN>)
id 1v62FK-0002gZ-1t
for 79584 <at> debbugs.gnu.org; Tue, 07 Oct 2025 03:36:30 -0400
From: Oliver Reiter <oliver.reiter@HIDDEN>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snapdragon.cc;
s=default; t=1759822586;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=tHDkALhrdP4Uo754X4DQnZQz62Rkm7w9A4JIj0DBtig=;
b=HQXSAI9G/r1/YHZf+Oaj4Pkon/4sK9PN01gtJfSDsNsRbNNjmNffVpcb2/TU2G9AImgbMa
mrmSVRGLIRqdp/TQFwKMld+kSciE7DEjXL11m8U+MlHIDKm87dJsxpbZQoDctelYLdR51+
ppbLrRHAqehaXElY6dcSv10GMmUX9aI=
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <86jz17cku0.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN>
<87ms63zxij.fsf@HIDDEN> <86jz17cku0.fsf@HIDDEN>
Date: Tue, 07 Oct 2025 09:36:23 +0200
Message-ID: <87v7kr6u4o.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79584
Cc: 79584 <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
Content-Disposition: inline
Eli Zaretskii <eliz@HIDDEN> writes:
>> From: Oliver Reiter <oliver.reiter@HIDDEN>
>> Cc: 79584 <at> debbugs.gnu.org
>> Date: Mon, 06 Oct 2025 20:38:12 +0200
>>
>> Eli Zaretskii <eliz@HIDDEN> writes:
>>
>> >> Date: Mon, 06 Oct 2025 14:04:47 +0200
>> >> From: Oliver Reiter via "Bug reports for GNU Emacs,
>> >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>> >>
>> >> #15 0x00007ffff187627b in F74696d65722d6576656e742d68616e646c6572_timer_event_handler_0 ()
>> >> from /home/reitero/build/sources/emacs/emacs_debug/src/../native-lisp/31.0.50-7aaa0ab0/preloaded/timer-3ee7cfd9-6ab3799c.eln
>> >
>> > Looks like a timer function wanted to print some message, and bumped
>> > into an invalid Lisp string or something?
>> >
>> > What does this produce:
>> >
>> > (gdb) frame 14
>> > (gdb) p args[0]
>> > (gdb) xtype
>> > (gdb) p args[1]
>> > (gdb) xtype
>> > (gdb) p args[2]
>> > (gdb) xtype
>> >
>> > For each type that the "xtype" command can print, we have a
>> > corresponding "xFOO" command, like "xstring" for Lisp strings,
>> > "xsymbol" for symbols, etc. So please use those immediately after
>> > each "xtype" to show the 3 arguments of that funcall. (I expect
>> > args[0] to be the symbol format-message and args[1] to be a format
>> > string.)
>>
>> You guessed very good:
>>
>> (gdb) frame 14
>> #14 0x0000555555703c3f in Ffuncall (nargs=3, args=0x7fffffffcda0) at /home/reitero/build/sources/emacs/emacs_debug/src/eval.c:3218
>> 3218 Lisp_Object val = funcall_general (args[0], nargs - 1, args + 1);
>> (gdb) p args[0]
>> $1 = XIL(0x2aaa8c3dee70)
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $2 = (struct Lisp_Symbol *) 0x7fffe1d0ae50
>> "format-message"
>> (gdb) p args[1]
>> $3 = XIL(0x7fffe1d68044)
>> (gdb) xtype
>> Lisp_String
>> (gdb) xstring
>> $4 = (struct Lisp_String *) 0x7fffe1d68040
>> " `%s'"
>> (gdb) p args[2]
>> $5 = XIL(0x2aaa8d087080)
>> (gdb) xtype
>> Lisp_Symbol
>> (gdb) xsymbol
>> $6 = (struct Lisp_Symbol *) 0x7fffe29b3060
>> 0
>
> So the symbol is bogus? What does the below show?
>
> (gdb) p *((struct Lisp_Symbol *) 0x7fffe29b3060)
(gdb) f 14
#14 0x0000555555703c3f in Ffuncall (nargs=3, args=0x7fffffffcda0) at /home/reitero/build/sources/emacs/emacs_debug/src/eval.c:3218
3218 Lisp_Object val = funcall_general (args[0], nargs - 1, args + 1);
(gdb) p *((struct Lisp_Symbol *) 0x7fffe29b3060)
$10 = {
gc_header = {
v = 30064771081,
gcaligned = 9 '\t'
},
u = {
s = {
gcmarkbit = false,
redirect = SYMBOL_PLAINVAL,
trapped_write = SYMBOL_NOWRITE,
interned = SYMBOL_INTERNED,
declared_special = false,
name = XIL(0x7fffe29b33b4),
val = {
value = XIL(0x70),
alias = 0x70,
blv = 0x70,
fwd = 0x70
},
function = XIL(0x7fffe29b33dd),
plist = XIL(0),
next = 0x7fffe29b3410
},
gcaligned = 40 '('
}
}
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 7 Oct 2025 06:03:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 07 02:03:49 2025 Received: from localhost ([127.0.0.1]:56362 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v60nd-0004M1-Aw for submit <at> debbugs.gnu.org; Tue, 07 Oct 2025 02:03:49 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37922) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1v60nb-0004Lo-4K for 79584 <at> debbugs.gnu.org; Tue, 07 Oct 2025 02:03:47 -0400 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 1v60nV-0005Dh-QB; Tue, 07 Oct 2025 02:03:41 -0400 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=xarn2msLmHuHT9B70dru/4GKrgOzDewm656E0xpaqiU=; b=H9kY/w3GR3Fm /VFMpHungui/XTAN30iLEGhK0APRsXQIWwql4o0ym+eeaPEN6kgYShj9oxtvTzqgbEujLN7skbxhC w59f/45tTLJDwmNBN7K3+bsEP2DymhLXxSREAeYgHbAZV+cseBguOxxjjqHf3+0owwScq7izEOt5G Ht7E9IVK1sc+6m3NVCeccAzU2QpjgvpednsATMDe67A+mNf3JubitbeTjdJHnBlN0m9uaaGAROvAT qDl9aiwn5SUOCzdU6oPDF2j+UwvD+3V0xvfSqdN9J2jbMuTqcTadHcVXc9Z/+vxpO2XidkSPt8+L2 RckIuAlWGaMKYxIsSq6lHQ==; Date: Tue, 07 Oct 2025 09:03:38 +0300 Message-Id: <86ikgrckp1.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Oliver Reiter <oliver.reiter@HIDDEN> In-Reply-To: <87ikgrzx7x.fsf@HIDDEN> (bug-gnu-emacs@HIDDEN) Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm References: <874iscb5i8.fsf_-_@HIDDEN> <87v7ksdmv5.fsf@HIDDEN> <87ikgrzx7x.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79584 Cc: pipcet@HIDDEN, 79584 <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: 79584 <at> debbugs.gnu.org > Date: Mon, 06 Oct 2025 20:44:34 +0200 > From: Oliver Reiter via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > > (gdb) p *XOBARRAY(Vobarray) > No symbol "Vobarray" in current context. Another problem with macros? How about this: (gdb) p *XOBARRAY(globals.f_Vobarray)
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 7 Oct 2025 06:00:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Oct 07 02:00:53 2025 Received: from localhost ([127.0.0.1]:56357 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v60kn-0004HX-Dl for submit <at> debbugs.gnu.org; Tue, 07 Oct 2025 02:00:53 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33600) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1v60kl-0004HJ-7t for 79584 <at> debbugs.gnu.org; Tue, 07 Oct 2025 02:00:51 -0400 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 1v60kd-0004bG-5v; Tue, 07 Oct 2025 02:00:43 -0400 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=lGnKGWWrYU0NMNMuJ8veMS7Hj2bI50cxNBlaQaLl0Y0=; b=IbQ0KQ3K3ahm 93vsyNg/ROpypCYmhbGTxtEnB6XcDf8kwzP08purohE9/3z2FLs3laQn4L6MQQlgZvXJD55q7ttjw +4LJmvSDcHJ42giVWsP9agNxR9zKzKEe9FKPaEmzuVToXfg2e4FCoOwPaS0dthqOKDdXIO8pFxzIi gem8juf0Yucsop8wDLQr1vpS9sdFMAzL8LkEshdTKnfidQ9GhSfMLgBjSeHBzoHaR+c0oDu7pSm2t L5RRsA1rBnpjpjFvONjLH7IVlQQJguMPiYBGrmgrPMuZF0+DI7X+KSdau00vJyutqCw1lLMPiwzHx e3XLMuNPSpqR3bWpSgcoFQ==; Date: Tue, 07 Oct 2025 09:00:39 +0300 Message-Id: <86jz17cku0.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Oliver Reiter <oliver.reiter@HIDDEN> In-Reply-To: <87ms63zxij.fsf@HIDDEN> (message from Oliver Reiter on Mon, 06 Oct 2025 20:38:12 +0200) Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN> <87ms63zxij.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 79584 Cc: 79584 <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: Oliver Reiter <oliver.reiter@HIDDEN> > Cc: 79584 <at> debbugs.gnu.org > Date: Mon, 06 Oct 2025 20:38:12 +0200 > > Eli Zaretskii <eliz@HIDDEN> writes: > > >> Date: Mon, 06 Oct 2025 14:04:47 +0200 > >> From: Oliver Reiter via "Bug reports for GNU Emacs, > >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> > >> > >> #15 0x00007ffff187627b in F74696d65722d6576656e742d68616e646c6572_timer_event_handler_0 () > >> from /home/reitero/build/sources/emacs/emacs_debug/src/../native-lisp/31.0.50-7aaa0ab0/preloaded/timer-3ee7cfd9-6ab3799c.eln > > > > Looks like a timer function wanted to print some message, and bumped > > into an invalid Lisp string or something? > > > > What does this produce: > > > > (gdb) frame 14 > > (gdb) p args[0] > > (gdb) xtype > > (gdb) p args[1] > > (gdb) xtype > > (gdb) p args[2] > > (gdb) xtype > > > > For each type that the "xtype" command can print, we have a > > corresponding "xFOO" command, like "xstring" for Lisp strings, > > "xsymbol" for symbols, etc. So please use those immediately after > > each "xtype" to show the 3 arguments of that funcall. (I expect > > args[0] to be the symbol format-message and args[1] to be a format > > string.) > > You guessed very good: > > (gdb) frame 14 > #14 0x0000555555703c3f in Ffuncall (nargs=3, args=0x7fffffffcda0) at /home/reitero/build/sources/emacs/emacs_debug/src/eval.c:3218 > 3218 Lisp_Object val = funcall_general (args[0], nargs - 1, args + 1); > (gdb) p args[0] > $1 = XIL(0x2aaa8c3dee70) > (gdb) xtype > Lisp_Symbol > (gdb) xsymbol > $2 = (struct Lisp_Symbol *) 0x7fffe1d0ae50 > "format-message" > (gdb) p args[1] > $3 = XIL(0x7fffe1d68044) > (gdb) xtype > Lisp_String > (gdb) xstring > $4 = (struct Lisp_String *) 0x7fffe1d68040 > " `%s'" > (gdb) p args[2] > $5 = XIL(0x2aaa8d087080) > (gdb) xtype > Lisp_Symbol > (gdb) xsymbol > $6 = (struct Lisp_Symbol *) 0x7fffe29b3060 > 0 So the symbol is bogus? What does the below show? (gdb) p *((struct Lisp_Symbol *) 0x7fffe29b3060)
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 6 Oct 2025 18:44:43 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 06 14:44:43 2025
Received: from localhost ([127.0.0.1]:55168 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v5qCR-0006ye-6w
for submit <at> debbugs.gnu.org; Mon, 06 Oct 2025 14:44:43 -0400
Received: from mail.snapdragon.cc ([2402:1f00:8001:f75::2]:44018)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <oliver.reiter@HIDDEN>)
id 1v5qCO-0006yT-G4
for 79584 <at> debbugs.gnu.org; Mon, 06 Oct 2025 14:44:41 -0400
From: Oliver Reiter <oliver.reiter@HIDDEN>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snapdragon.cc;
s=default; t=1759776277;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
in-reply-to:in-reply-to:references:references;
bh=BPStJkN0F1qI5rI/eERXVevvI7tgSADnqITLixVQ0H4=;
b=MJn/fYUBqH59SIMRxFCqD0gMcZcWfx3HY+W0v+D3lapywK053VnLrYDtCHjqD1ViNMk/96
Sus0hB8sIsxlI6Ik9iQzVfzLbZgJ39QGN152hdC0RCdkkRO4E5KZeuWCUcXxP2O0sNYIuJ
XnAgNrWVpfT3CsuNWxOZPgo7h/eNE4c=
To: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
In-Reply-To: <87v7ksdmv5.fsf@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN> <87v7ksdmv5.fsf@HIDDEN>
Date: Mon, 06 Oct 2025 20:44:34 +0200
Message-ID: <87ikgrzx7x.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 79584
Cc: 79584 <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
Content-Disposition: inline
Pip Cet <pipcet@HIDDEN> writes:
> "Oliver Reiter via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" <bug-gnu-emacs@HIDDEN> writes:
>> #10 0x00005555556fdb0f in styled_format (nargs=<optimized out>, args=<optimized out>, message=message@entry=true) at /home/reitero/build/sources/emacs/emacs_debug/src/editfns.c:3745
>
> It looks like the argument to styled_format, which should have been
> intern("vterm--delayed-redraw"), wasn't properly traced during the last GC: the
> symbol name still has the string tag, but the actual string metadata is
> corrupt.
>
> Do you still have a live session? Again, we should be looking at the
> initial obarray, and finding out why it contains invalid data.
>
> If you do, please try
>
> p intern("vterm--delayed-redraw")
> p *XSYMBOL(intern("vterm--delayed-redraw"))
>
Yes, I still have the live session:
(gdb) p intern("vterm--delayed-redraw")
$7 = (struct Lisp_X *) 0x2aaa8fa9eb48
(gdb) p *XSYMBOL(intern("vterm--delayed-redraw"))
$8 = {
gc_header = {
v = 31788899857,
gcaligned = 17 '\021'
},
u = {
s = {
gcmarkbit = false,
redirect = SYMBOL_PLAINVAL,
trapped_write = SYMBOL_UNTRAPPED_WRITE,
interned = SYMBOL_INTERNED_IN_INITIAL_OBARRAY,
declared_special = false,
name = XIL(0x7fffe5b21e74),
val = {
value = XIL(0x70),
alias = 0x70,
blv = 0x70,
fwd = 0x70
},
function = XIL(0x7fffe5b21e9d),
plist = XIL(0),
next = 0x7fffe5b21ed0
},
gcaligned = 64 '@'
}
}
> In either case, can you please do:
>
> p *XOBARRAY(initial_obarray)
> p *XOBARRAY(Vobarray)
(gdb) p *XOBARRAY(initial_obarray)
$9 = {
header = {
gc_header = {
v = 17179870497,
gcaligned = 33 '!'
},
size = 4611686018695831552
},
buckets = 0x7fffe6825010,
size_bits = 17,
count = 103537
}
(gdb) p *XOBARRAY(Vobarray)
No symbol "Vobarray" in current context.
Happy to help,
Oliver
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.Received: (at 79584) by debbugs.gnu.org; 6 Oct 2025 18:38:24 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 06 14:38:23 2025 Received: from localhost ([127.0.0.1]:55161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v5q6J-0006i7-Co for submit <at> debbugs.gnu.org; Mon, 06 Oct 2025 14:38:23 -0400 Received: from mail.snapdragon.cc ([51.79.228.117]:37526) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <oliver.reiter@HIDDEN>) id 1v5q6G-0006ht-0p for 79584 <at> debbugs.gnu.org; Mon, 06 Oct 2025 14:38:21 -0400 From: Oliver Reiter <oliver.reiter@HIDDEN> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snapdragon.cc; s=default; t=1759775896; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=JoMJAsMzHoAodWRhMOId4+DlJsP5DVZnHXtcb3ZLpVA=; b=RAbMvW/xqxfoHiDjnAHLMUbIAdV6twCCKgIDi/S2exyykGMrU9xTFGJ30yTskGBnfxB3Qm 87mXOqvXxKWuJb66yVACjziCtu2Wzu657nMbX3qtNAHjSfFyN2d7bLeeUY36BpBf1gagX4 pfZ31a3cq9yyk8D/q9UGo/NzZSty4dQ= To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm In-Reply-To: <86qzvgccp9.fsf@HIDDEN> References: <874iscb5i8.fsf_-_@HIDDEN> <86qzvgccp9.fsf@HIDDEN> Date: Mon, 06 Oct 2025 20:38:12 +0200 Message-ID: <87ms63zxij.fsf@HIDDEN> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 79584 Cc: 79584 <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 Content-Disposition: inline Eli Zaretskii <eliz@HIDDEN> writes: >> Date: Mon, 06 Oct 2025 14:04:47 +0200 >> From: Oliver Reiter via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN> >> >> #15 0x00007ffff187627b in F74696d65722d6576656e742d68616e646c6572_timer_event_handler_0 () >> from /home/reitero/build/sources/emacs/emacs_debug/src/../native-lisp/31.0.50-7aaa0ab0/preloaded/timer-3ee7cfd9-6ab3799c.eln > > Looks like a timer function wanted to print some message, and bumped > into an invalid Lisp string or something? > > What does this produce: > > (gdb) frame 14 > (gdb) p args[0] > (gdb) xtype > (gdb) p args[1] > (gdb) xtype > (gdb) p args[2] > (gdb) xtype > > For each type that the "xtype" command can print, we have a > corresponding "xFOO" command, like "xstring" for Lisp strings, > "xsymbol" for symbols, etc. So please use those immediately after > each "xtype" to show the 3 arguments of that funcall. (I expect > args[0] to be the symbol format-message and args[1] to be a format > string.) You guessed very good: (gdb) frame 14 #14 0x0000555555703c3f in Ffuncall (nargs=3, args=0x7fffffffcda0) at /home/reitero/build/sources/emacs/emacs_debug/src/eval.c:3218 3218 Lisp_Object val = funcall_general (args[0], nargs - 1, args + 1); (gdb) p args[0] $1 = XIL(0x2aaa8c3dee70) (gdb) xtype Lisp_Symbol (gdb) xsymbol $2 = (struct Lisp_Symbol *) 0x7fffe1d0ae50 "format-message" (gdb) p args[1] $3 = XIL(0x7fffe1d68044) (gdb) xtype Lisp_String (gdb) xstring $4 = (struct Lisp_String *) 0x7fffe1d68040 " `%s'" (gdb) p args[2] $5 = XIL(0x2aaa8d087080) (gdb) xtype Lisp_Symbol (gdb) xsymbol $6 = (struct Lisp_Symbol *) 0x7fffe29b3060 0 > > The TO argument of this call: > >> #9 lisp_string_width (string=0x7fffe29b33b4, from=0, to=140737047043696, precision=-1, nchars=0x7fffffff74a8, nbytes=0x7fffffff74a0, auto_comp=false) > > looks bogus, which might mean that the string we are trying to print > is invalid, like if it was GC'ed or something. --=-=-=--
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 6 Oct 2025 16:21:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 06 12:21:13 2025
Received: from localhost ([127.0.0.1]:55010 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v5nxZ-00008N-AQ
for submit <at> debbugs.gnu.org; Mon, 06 Oct 2025 12:21:13 -0400
Received: from mail-10631.protonmail.ch ([79.135.106.31]:47471)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <pipcet@HIDDEN>)
id 1v5nxR-00007L-BE
for 79584 <at> debbugs.gnu.org; Mon, 06 Oct 2025 12:21:07 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1759767657; x=1760026857;
bh=+ZjhjgjzI3i7zZ/01nj6RSa7WBBECI0rApcgrLAqIJM=;
h=Date:To:From:Subject:Message-ID:In-Reply-To:References:
Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
Message-ID:BIMI-Selector;
b=V7MNmhPh+erruWnGuTnXdrddUmzgbymPLzhG4UMltkg96P/P6BzBCofTdDm4dElLh
myP/zrLXwdywtJeokGGZuVCKJlw99bcE4JkvHGAOJX6vX3kHIA/m7XhKLiGfoIYofR
Zf4KGP0oNyxvqqHMN3EMfkvwxI7TobhHmDU5oIwnc/KteSiU0WutxHV60TPsG/v6bZ
WlQ0zknepnQZtsEvEzivh3ZyvfCQV93oE0kMJLaDuOVTx+MfxGh5i8gRuhegzmTfx2
uqd4mSVmoXHqA64azvpqzPeOdxxte6NVAqvr/20kLcKah2NfmjYhLpcHqHNiR1vwKP
q8MZkiDdksObQ==
Date: Mon, 06 Oct 2025 16:20:54 +0000
To: 79584 <at> debbugs.gnu.org, Oliver Reiter <oliver.reiter@HIDDEN>
From: Pip Cet <pipcet@HIDDEN>
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
Message-ID: <87v7ksdmv5.fsf@HIDDEN>
In-Reply-To: <874iscb5i8.fsf_-_@HIDDEN>
References: <874iscb5i8.fsf_-_@HIDDEN>
Feedback-ID: 112775352:user:proton
X-Pm-Message-ID: ec0519d4f617a5d608cef7703c1e9ad58061c2fb
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: 79584
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 (-)
"Oliver Reiter via \"Bug reports for GNU Emacs, the Swiss army knife of tex=
t editors\"" <bug-gnu-emacs@HIDDEN> writes:
> Dear all,
>
> I hid a crash similar to #79541 and #79542, this time using a -Og
> build. The bug is also reported downstream, see here
> <https://github.com/akermu/emacs-libvterm/issues/780>
Thanks!
> (gdb) bt full
> #9 lisp_string_width (string=3D0x7fffe29b33b4, from=3D0, to=3D1407370470=
43696, precision=3D-1, nchars=3D0x7fffffff74a8, nbytes=3D0x7fffffff74a0, au=
to_comp=3Dfalse)
> at /home/reitero/build/sources/emacs/emacs_debug/src/character.c:437
> c =3D <optimized out>
> str =3D 0x7fffe299f788 "\210R\262\345\377\177"
> cbytes =3D <optimized out>
> chars =3D <optimized out>
> bytes =3D <optimized out>
> val =3D 0x0
> cmp_id =3D <optimized out>
> ignore =3D 93824993934792
> end =3D 140737488319152
> --Type <RET> for more, q to quit, c to continue without paging--c
> thiswidth =3D <optimized out>
> multibyte =3D false
> i =3D 23459960
> i_byte =3D 23459960
> from_byte =3D 0
> width =3D 41090795
> dp =3D 0x7fffe1c56108
> f =3D <optimized out>
> font_width =3D -1
> default_font =3D <optimized out>
> frame_font =3D <optimized out>
> #10 0x00005555556fdb0f in styled_format (nargs=3D<optimized out>, args=3D=
<optimized out>, message=3Dmessage@entry=3Dtrue) at /home/reitero/build/sou=
rces/emacs/emacs_debug/src/editfns.c:3745
It looks like the argument to styled_format, which should have been
intern("vterm--delayed-redraw"), wasn't properly traced during the last GC:=
the
symbol name still has the string tag, but the actual string metadata is
corrupt.
Do you still have a live session? Again, we should be looking at the
initial obarray, and finding out why it contains invalid data.
If you do, please try
p intern("vterm--delayed-redraw")
p *XSYMBOL(intern("vterm--delayed-redraw"))
In either case, can you please do:
p *XOBARRAY(initial_obarray)
p *XOBARRAY(Vobarray)
(all after running "source src/.gdbinit", if required).
Thanks!
Pip
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at 79584) by debbugs.gnu.org; 6 Oct 2025 14:44:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 06 10:44:18 2025
Received: from localhost ([127.0.0.1]:54864 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v5mRl-0003qf-QK
for submit <at> debbugs.gnu.org; Mon, 06 Oct 2025 10:44:18 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:49622)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1v5mRi-0003qO-7y
for 79584 <at> debbugs.gnu.org; Mon, 06 Oct 2025 10:44:15 -0400
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 1v5mRb-0006hh-Db; Mon, 06 Oct 2025 10:44:07 -0400
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=NMArE/Hi0mnL+N1W9nMBHq2CX6midGAtmfuKVAsYCe4=; b=bbQtG74NjslG8T8Srit3
bsGFXmtkTH4iPDvpSHS0pc5/y51X69GHMenVllFuPckOzweU4bTl/GYbQ2lAxVUAyesoGd7QPGHYW
/ofxiFQX91b5Nd3Y9VRYa0tE2IPZZTpRF3Do3PLI20dajbr07kwHrWmMJhcG4OAT6a1UkgUvKeCNf
gOD92fsfM1NkHGwwJcfNlpsN9XBvjMSnQvjzC+wlfJqafX64sbepV6jrfxngajI9rLP/608/UAyyw
afFGx8oKqASfB4mnMMN7EFxvP4I68lYqBrLTk24ZdMlWN8bXbLkBSRDkxS05UUlT16JKabcqsfnXA
CRrCYakF7bCGWw==;
Date: Mon, 06 Oct 2025 17:44:02 +0300
Message-Id: <86qzvgccp9.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Oliver Reiter <oliver.reiter@HIDDEN>
In-Reply-To: <874iscb5i8.fsf_-_@HIDDEN> (bug-gnu-emacs@HIDDEN)
Subject: Re: bug#79584: 31.0.50; feature/igc: crash #3 using vterm
References: <874iscb5i8.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: 79584
Cc: 79584 <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: Mon, 06 Oct 2025 14:04:47 +0200
> From: Oliver Reiter via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>
> I hid a crash similar to #79541 and #79542, this time using a -Og
> build. The bug is also reported downstream, see here
> <https://github.com/akermu/emacs-libvterm/issues/780>
>
>
> (gdb) bt full
> #0 terminate_due_to_signal (sig=11, backtrace_limit=40) at /home/reitero/build/sources/emacs/emacs_debug/src/emacs.c:443
> No locals.
> #1 0x000055555569a7a7 in handle_fatal_signal (sig=sig@entry=11) at /home/reitero/build/sources/emacs/emacs_debug/src/sysdep.c:1793
> No locals.
> #2 0x000055555569a733 in deliver_thread_signal (sig=sig@entry=11, handler=handler@entry=0x55555569a799 <handle_fatal_signal>) at /home/reitero/build/sources/emacs/emacs_debug/src/sysdep.c:1785
> old_errno = 11
> #3 0x000055555569a797 in deliver_fatal_thread_signal (sig=sig@entry=11) at /home/reitero/build/sources/emacs/emacs_debug/src/sysdep.c:1805
> No locals.
> #4 0x000055555569a7e9 in handle_sigsegv (sig=11, siginfo=<optimized out>, arg=<optimized out>) at /home/reitero/build/sources/emacs/emacs_debug/src/sysdep.c:1943
> fatal = <optimized out>
> #5 <signal handler called>
> No locals.
> #6 0x00007ffff343e74b in __GI_kill () at ../sysdeps/unix/syscall-template.S:120
> No locals.
> #7 0x000055555582cec4 in sigHandle (sig=<optimized out>, info=0x7fffffff6d70, uap=0x7fffffff6c40) at ../mps/code/protsgix.c:114
> e = <optimized out>
> sa = {
> __sigaction_handler = {
> sa_handler = 0x55555582cdf9 <sigHandle>,
> sa_sigaction = 0x55555582cdf9 <sigHandle>
> },
> sa_mask = {
> __val = {0, 140737488316864, 93824995187918, 140737488316880, 93824994882522, 140737488316976, 93824994915173, 8192, 140736945917896, 140737077911552, 17862165311548904192, 0, 140737249476608,
> 140737488317808, 11, 140737488316992}
> },
> sa_flags = 335544324,
> sa_restorer = 0x7ffff343e540 <__restore_rt>
> }
> context = <optimized out>
> asigset = {
> __val = {1024, 93824995065000, 16384, 140737353842008, 140737488317232, 93824995066172, 140737353842008, 140737353841968, 8192, 140737177433904, 140737488317280, 17862165311548904192, 140737353839296,
> 140736942690320, 1216, 140736942690320}
> }
> oldset = {
> __val = {1024, 93824994996048, 140737146370992, 140737488317056, 140737146370672, 0, 140737488317104, 17862165311548904192, 140737488317696, 93824995066172, 93824995052682, 93824995055592,
> 140737353842008, 93824995052682, 140737488317232, 17862165311548904192}
> }
> mode = <optimized out>
> base = <optimized out>
> _saved_errno = 11
> #8 <signal handler called>
> No locals.
> #9 lisp_string_width (string=0x7fffe29b33b4, from=0, to=140737047043696, precision=-1, nchars=0x7fffffff74a8, nbytes=0x7fffffff74a0, auto_comp=false)
> at /home/reitero/build/sources/emacs/emacs_debug/src/character.c:437
> c = <optimized out>
> str = 0x7fffe299f788 "\210R\262\345\377\177"
> cbytes = <optimized out>
> chars = <optimized out>
> bytes = <optimized out>
> val = 0x0
> cmp_id = <optimized out>
> ignore = 93824993934792
> end = 140737488319152
> --Type <RET> for more, q to quit, c to continue without paging--c
> thiswidth = <optimized out>
> multibyte = false
> i = 23459960
> i_byte = 23459960
> from_byte = 0
> width = 41090795
> dp = 0x7fffe1c56108
> f = <optimized out>
> font_width = -1
> default_font = <optimized out>
> frame_font = <optimized out>
> #10 0x00005555556fdb0f in styled_format (nargs=<optimized out>, args=<optimized out>, message=message@entry=true) at /home/reitero/build/sources/emacs/emacs_debug/src/editfns.c:3745
> nch = 54
> nby = 58
> prec = <optimized out>
> nchars_string = <optimized out>
> padding = <optimized out>
> width = <optimized out>
> nbytes = <optimized out>
> plus_flag = <optimized out>
> field_width = <optimized out>
> num = <optimized out>
> num_end = 0x7fffffff7363 "s'"
> space_flag = <optimized out>
> sharp_flag = <optimized out>
> precision = <optimized out>
> arg = <optimized out>
> float_conversion = <optimized out>
> zero_flag = <optimized out>
> conversion = <optimized out>
> spec_index = <optimized out>
> minus_flag = <optimized out>
> precision_given = <optimized out>
> spec = <optimized out>
> p = <optimized out>
> n0 = <optimized out>
> ispec0 = <optimized out>
> format0 = 0x7fffffff7362 "%s'"
> convbytes = 1
> convsrc = 0x7fffffff7362 "%s'"
> format_char = <optimized out>
> used = <optimized out>
> buflen_needed = <optimized out>
> n = <optimized out>
> initial_buffer = " ‘\377\177\000\000iMwUUU\000\000K\024\312\343\377\177\000\000:\000\000\000\000\000\000\000\360t\377\377\377\177\000\000\204\237pUUU\000\000@u\377\377\377\177\000\000\320w\031VUU\000\000@u\377\377\377\177\000\000\264\337pUUU\000\000@u\377\377\377\177\000\000\200u\377\377\377\177\000\000\002\000\000\000\000\000\000\000\376\236pUUU\000\000\200u\377\377\377\177\000\000\003\000\000\000\000\000\000\000@v\377\377\377\177\000\000\255\001qUUU\000\000\003\000\000\000\000\000\000\000\000w\377\377\377\177", '\000' <repeats 18 times>, "\001\000\000\000\000\000\000\000\001\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\r\000"...
> buf = <optimized out>
> bufsize = <optimized out>
> max_bufsize = 2305843009213693952
> p = 0x7fffffff74c4 "\377\177"
> buf_save_value_index = <optimized out>
> format = 0x7fffffff7364 "'"
> end = <optimized out>
> nchars = <optimized out>
> maybe_combine_byte = <optimized out>
> val = <optimized out>
> arg_intervals = <optimized out>
> sa_avail = <optimized out>
> sa_count = <optimized out>
> info = <optimized out>
> multibyte_format = <optimized out>
> formatlen = <optimized out>
> format_start = <optimized out>
> fmt_props = <optimized out>
> nspec_bound = <optimized out>
> info_size = <optimized out>
> alloca_size = <optimized out>
> spec_arguments = <optimized out>
> discarded = <optimized out>
> multibyte = <optimized out>
> quoting_style = <optimized out>
> ispec = <optimized out>
> nspec = <optimized out>
> new_result = <optimized out>
> USEFUL_PRECISION_MAX = USEFUL_PRECISION_MAX
> SPRINTF_BUFSIZE = SPRINTF_BUFSIZE
> CONVBYTES_ROOM = CONVBYTES_ROOM
> pMlen = pMlen
> #11 0x00005555556fee98 in Fformat_message (nargs=<optimized out>, args=<optimized out>) at /home/reitero/build/sources/emacs/emacs_debug/src/editfns.c:3428
> No locals.
> #12 0x000055555570395a in funcall_subr (subr=0x55555591c320 <Sformat_message>, numargs=numargs@entry=2, args=args@entry=0x7fffffffcda8) at /home/reitero/build/sources/emacs/emacs_debug/src/eval.c:3309
> maxargs = -2
> fun = <optimized out>
> #13 0x0000555555703b2f in funcall_general (fun=0x55555591c325 <Sformat_message+5>, numargs=numargs@entry=2, args=args@entry=0x7fffffffcda8) at /home/reitero/build/sources/emacs/emacs_debug/src/eval.c:3165
> original_fun = 0x2aaa8c3dee70
> #14 0x0000555555703c3f in Ffuncall (nargs=3, args=0x7fffffffcda0) at /home/reitero/build/sources/emacs/emacs_debug/src/eval.c:3218
> count = {
> bytes = 256
> }
> val = <optimized out>
> #15 0x00007ffff187627b in F74696d65722d6576656e742d68616e646c6572_timer_event_handler_0 ()
> from /home/reitero/build/sources/emacs/emacs_debug/src/../native-lisp/31.0.50-7aaa0ab0/preloaded/timer-3ee7cfd9-6ab3799c.eln
Looks like a timer function wanted to print some message, and bumped
into an invalid Lisp string or something?
What does this produce:
(gdb) frame 14
(gdb) p args[0]
(gdb) xtype
(gdb) p args[1]
(gdb) xtype
(gdb) p args[2]
(gdb) xtype
For each type that the "xtype" command can print, we have a
corresponding "xFOO" command, like "xstring" for Lisp strings,
"xsymbol" for symbols, etc. So please use those immediately after
each "xtype" to show the 3 arguments of that funcall. (I expect
args[0] to be the symbol format-message and args[1] to be a format
string.)
The TO argument of this call:
> #9 lisp_string_width (string=0x7fffe29b33b4, from=0, to=140737047043696, precision=-1, nchars=0x7fffffff74a8, nbytes=0x7fffffff74a0, auto_comp=false)
looks bogus, which might mean that the string we are trying to print
is invalid, like if it was GC'ed or something.
bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 6 Oct 2025 12:05:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Oct 06 08:05:28 2025
Received: from localhost ([127.0.0.1]:54295 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1v5jy3-0002vE-F1
for submit <at> debbugs.gnu.org; Mon, 06 Oct 2025 08:05:28 -0400
Received: from lists.gnu.org ([2001:470:142::17]:54730)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <oliver.reiter@HIDDEN>)
id 1v5jxy-0002pu-IJ
for submit <at> debbugs.gnu.org; Mon, 06 Oct 2025 08:05:24 -0400
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 <oliver.reiter@HIDDEN>)
id 1v5jxl-0001Gg-61
for bug-gnu-emacs@HIDDEN; Mon, 06 Oct 2025 08:05:09 -0400
Received: from mail.snapdragon.cc ([2402:1f00:8001:f75::2])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <oliver.reiter@HIDDEN>)
id 1v5jxZ-0003r2-WD
for bug-gnu-emacs@HIDDEN; Mon, 06 Oct 2025 08:05:08 -0400
From: Oliver Reiter <oliver.reiter@HIDDEN>
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=snapdragon.cc;
s=default; t=1759752290;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:mime-version:mime-version:content-type:content-type;
bh=t5+dcTRz+jhmR2HyHSTEfZfe2Wwbe5V2l6VCecJG2lc=;
b=Qus91obxUPLAa75yKSKjaeTQBRCW+AJ32jXkKikXAztvNKOlZqJ4BAaZzICt4F9RGruS2D
0IIbdy5xdPAn4inkjXAlPyA19IWd3r0tXox52HeVDmTS1bkYw0M9uGiObHSYBtMMqVP9A4
S7LrWm5UdwsWFUe3wV1WgyEkVzAiicY=
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; feature/igc: crash #3 using vterm
X-Debbugs-Cc:
Date: Mon, 06 Oct 2025 14:04:47 +0200
Message-ID: <874iscb5i8.fsf_-_@HIDDEN>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=2402:1f00:8001:f75::2;
envelope-from=oliver.reiter@HIDDEN; helo=mail.snapdragon.cc
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_NONE=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
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 (/)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Dear all,
I hid a crash similar to #79541 and #79542, this time using a -Og
build. The bug is also reported downstream, see here
<https://github.com/akermu/emacs-libvterm/issues/780>
(gdb) bt full
#0 terminate_due_to_signal (sig=3D11, backtrace_limit=3D40) at /home/reite=
ro/build/sources/emacs/emacs_debug/src/emacs.c:443
No locals.
#1 0x000055555569a7a7 in handle_fatal_signal (sig=3Dsig@entry=3D11) at /ho=
me/reitero/build/sources/emacs/emacs_debug/src/sysdep.c:1793
No locals.
#2 0x000055555569a733 in deliver_thread_signal (sig=3Dsig@entry=3D11, hand=
ler=3Dhandler@entry=3D0x55555569a799 <handle_fatal_signal>) at /home/reiter=
o/build/sources/emacs/emacs_debug/src/sysdep.c:1785
old_errno =3D 11
#3 0x000055555569a797 in deliver_fatal_thread_signal (sig=3Dsig@entry=3D11=
) at /home/reitero/build/sources/emacs/emacs_debug/src/sysdep.c:1805
No locals.
#4 0x000055555569a7e9 in handle_sigsegv (sig=3D11, siginfo=3D<optimized ou=
t>, arg=3D<optimized out>) at /home/reitero/build/sources/emacs/emacs_debug=
/src/sysdep.c:1943
fatal =3D <optimized out>
#5 <signal handler called>
No locals.
#6 0x00007ffff343e74b in __GI_kill () at ../sysdeps/unix/syscall-template.=
S:120
No locals.
#7 0x000055555582cec4 in sigHandle (sig=3D<optimized out>, info=3D0x7fffff=
ff6d70, uap=3D0x7fffffff6c40) at ../mps/code/protsgix.c:114
e =3D <optimized out>
sa =3D {
__sigaction_handler =3D {
sa_handler =3D 0x55555582cdf9 <sigHandle>,
sa_sigaction =3D 0x55555582cdf9 <sigHandle>
},
sa_mask =3D {
__val =3D {0, 140737488316864, 93824995187918, 140737488316880,=
93824994882522, 140737488316976, 93824994915173, 8192, 140736945917896, 14=
0737077911552, 17862165311548904192, 0, 140737249476608,=20
140737488317808, 11, 140737488316992}
},
sa_flags =3D 335544324,
sa_restorer =3D 0x7ffff343e540 <__restore_rt>
}
context =3D <optimized out>
asigset =3D {
__val =3D {1024, 93824995065000, 16384, 140737353842008, 14073748=
8317232, 93824995066172, 140737353842008, 140737353841968, 8192, 1407371774=
33904, 140737488317280, 17862165311548904192, 140737353839296,=20
140736942690320, 1216, 140736942690320}
}
oldset =3D {
__val =3D {1024, 93824994996048, 140737146370992, 140737488317056=
, 140737146370672, 0, 140737488317104, 17862165311548904192, 14073748831769=
6, 93824995066172, 93824995052682, 93824995055592,=20
140737353842008, 93824995052682, 140737488317232, 1786216531154=
8904192}
}
mode =3D <optimized out>
base =3D <optimized out>
_saved_errno =3D 11
#8 <signal handler called>
No locals.
#9 lisp_string_width (string=3D0x7fffe29b33b4, from=3D0, to=3D140737047043=
696, precision=3D-1, nchars=3D0x7fffffff74a8, nbytes=3D0x7fffffff74a0, auto=
_comp=3Dfalse)
at /home/reitero/build/sources/emacs/emacs_debug/src/character.c:437
c =3D <optimized out>
str =3D 0x7fffe299f788 "\210R\262\345\377\177"
cbytes =3D <optimized out>
chars =3D <optimized out>
bytes =3D <optimized out>
val =3D 0x0
cmp_id =3D <optimized out>
ignore =3D 93824993934792
end =3D 140737488319152
--Type <RET> for more, q to quit, c to continue without paging--c
thiswidth =3D <optimized out>
multibyte =3D false
i =3D 23459960
i_byte =3D 23459960
from_byte =3D 0
width =3D 41090795
dp =3D 0x7fffe1c56108
f =3D <optimized out>
font_width =3D -1
default_font =3D <optimized out>
frame_font =3D <optimized out>
#10 0x00005555556fdb0f in styled_format (nargs=3D<optimized out>, args=3D<o=
ptimized out>, message=3Dmessage@entry=3Dtrue) at /home/reitero/build/sourc=
es/emacs/emacs_debug/src/editfns.c:3745
nch =3D 54
nby =3D 58
prec =3D <optimized out>
nchars_string =3D <optimized out>
padding =3D <optimized out>
width =3D <optimized out>
nbytes =3D <optimized out>
plus_flag =3D <optimized out>
field_width =3D <optimized out>
num =3D <optimized out>
num_end =3D 0x7fffffff7363 "s'"
space_flag =3D <optimized out>
sharp_flag =3D <optimized out>
precision =3D <optimized out>
arg =3D <optimized out>
float_conversion =3D <optimized out>
zero_flag =3D <optimized out>
conversion =3D <optimized out>
spec_index =3D <optimized out>
minus_flag =3D <optimized out>
precision_given =3D <optimized out>
spec =3D <optimized out>
p =3D <optimized out>
n0 =3D <optimized out>
ispec0 =3D <optimized out>
format0 =3D 0x7fffffff7362 "%s'"
convbytes =3D 1
convsrc =3D 0x7fffffff7362 "%s'"
format_char =3D <optimized out>
used =3D <optimized out>
buflen_needed =3D <optimized out>
n =3D <optimized out>
initial_buffer =3D " =E2=80=98\377\177\000\000iMwUUU\000\000K\024\3=
12\343\377\177\000\000:\000\000\000\000\000\000\000\360t\377\377\377\177\00=
0\000\204\237pUUU\000\000@u\377\377\377\177\000\000\320w\031VUU\000\000@u\3=
77\377\377\177\000\000\264\337pUUU\000\000@u\377\377\377\177\000\000\200u\3=
77\377\377\177\000\000\002\000\000\000\000\000\000\000\376\236pUUU\000\000\=
200u\377\377\377\177\000\000\003\000\000\000\000\000\000\000@v\377\377\377\=
177\000\000\255\001qUUU\000\000\003\000\000\000\000\000\000\000\000w\377\37=
7\377\177", '\000' <repeats 18 times>, "\001\000\000\000\000\000\000\000\00=
1\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000\r\000"...
buf =3D <optimized out>
bufsize =3D <optimized out>
max_bufsize =3D 2305843009213693952
p =3D 0x7fffffff74c4 "\377\177"
buf_save_value_index =3D <optimized out>
format =3D 0x7fffffff7364 "'"
end =3D <optimized out>
nchars =3D <optimized out>
maybe_combine_byte =3D <optimized out>
val =3D <optimized out>
arg_intervals =3D <optimized out>
sa_avail =3D <optimized out>
sa_count =3D <optimized out>
info =3D <optimized out>
multibyte_format =3D <optimized out>
formatlen =3D <optimized out>
format_start =3D <optimized out>
fmt_props =3D <optimized out>
nspec_bound =3D <optimized out>
info_size =3D <optimized out>
alloca_size =3D <optimized out>
spec_arguments =3D <optimized out>
discarded =3D <optimized out>
multibyte =3D <optimized out>
quoting_style =3D <optimized out>
ispec =3D <optimized out>
nspec =3D <optimized out>
new_result =3D <optimized out>
USEFUL_PRECISION_MAX =3D USEFUL_PRECISION_MAX
SPRINTF_BUFSIZE =3D SPRINTF_BUFSIZE
CONVBYTES_ROOM =3D CONVBYTES_ROOM
pMlen =3D pMlen
#11 0x00005555556fee98 in Fformat_message (nargs=3D<optimized out>, args=3D=
<optimized out>) at /home/reitero/build/sources/emacs/emacs_debug/src/editf=
ns.c:3428
No locals.
#12 0x000055555570395a in funcall_subr (subr=3D0x55555591c320 <Sformat_mess=
age>, numargs=3Dnumargs@entry=3D2, args=3Dargs@entry=3D0x7fffffffcda8) at /=
home/reitero/build/sources/emacs/emacs_debug/src/eval.c:3309
maxargs =3D -2
fun =3D <optimized out>
#13 0x0000555555703b2f in funcall_general (fun=3D0x55555591c325 <Sformat_me=
ssage+5>, numargs=3Dnumargs@entry=3D2, args=3Dargs@entry=3D0x7fffffffcda8) =
at /home/reitero/build/sources/emacs/emacs_debug/src/eval.c:3165
original_fun =3D 0x2aaa8c3dee70
#14 0x0000555555703c3f in Ffuncall (nargs=3D3, args=3D0x7fffffffcda0) at /h=
ome/reitero/build/sources/emacs/emacs_debug/src/eval.c:3218
count =3D {
bytes =3D 256
}
val =3D <optimized out>
#15 0x00007ffff187627b in F74696d65722d6576656e742d68616e646c6572_timer_eve=
nt_handler_0 ()
from /home/reitero/build/sources/emacs/emacs_debug/src/../native-lisp/31=
.0.50-7aaa0ab0/preloaded/timer-3ee7cfd9-6ab3799c.eln
No symbol table info available.
#16 0x0000555555703875 in funcall_subr (subr=3D0x7fffe1cd5e48, numargs=3Dnu=
margs@entry=3D1, args=3Dargs@entry=3D0x7fffffffcf68) at /home/reitero/build=
/sources/emacs/emacs_debug/src/eval.c:3286
argbuf =3D {0x7fffffffce30, 0x555555701bc0 <BASE_EQ+26>, 0x7fffe1d6=
79dd, 0x1, 0x7fffffffce50, 0x555555701bc0 <BASE_EQ+26>, 0x0, 0x1}
a =3D <optimized out>
maxargs =3D 1
fun =3D <optimized out>
#17 0x0000555555703b2f in funcall_general (fun=3D0x7fffe1cd5e4d, numargs=3D=
numargs@entry=3D1, args=3Dargs@entry=3D0x7fffffffcf68) at /home/reitero/bui=
ld/sources/emacs/emacs_debug/src/eval.c:3165
original_fun =3D 0x14ee8
#18 0x0000555555703c3f in Ffuncall (nargs=3D2, args=3D0x7fffffffcf60) at /h=
ome/reitero/build/sources/emacs/emacs_debug/src/eval.c:3218
count =3D {
bytes =3D 192
}
val =3D <optimized out>
#19 0x0000555555683ec9 in timer_check_2 (timers=3D<optimized out>, timers@e=
ntry=3D0x7fffe3ca14c3, idle_timers=3D<optimized out>, idle_timers@entry=3D0=
x7fffe3ca150b)
at /home/reitero/build/sources/emacs/emacs_debug/src/keyboard.c:4833
idle_timer_ripe =3D <optimized out>
chosen_timer =3D 0x7fffe3c758e5
timer =3D 0x7fffe3c758e5
timer_difference =3D <optimized out>
idle_timer_difference =3D <optimized out>
ripe =3D <optimized out>
timer_time =3D <optimized out>
count =3D <optimized out>
idle_timer =3D <optimized out>
difference =3D <optimized out>
timer_ripe =3D true
old_deactivate_mark =3D <optimized out>
now =3D <optimized out>
idleness_now =3D <optimized out>
#20 0x0000555555689889 in timer_check () at /home/reitero/build/sources/ema=
cs/emacs_debug/src/keyboard.c:4898
nexttime =3D <optimized out>
timers =3D 0x7fffe3ca14c3
idle_timers =3D 0x7fffe3ca150b
tem =3D 0x0
#21 0x000055555575b9bd in wait_reading_process_output (time_limit=3D<optimi=
zed out>, nsecs=3D<optimized out>, read_kbd=3D-1, do_display=3Dtrue, wait_f=
or_cell=3D0x0, wait_proc=3D<optimized out>, just_wait_proc=3D0)
at /home/reitero/build/sources/emacs/emacs_debug/src/process.c:5487
old_timers_run =3D 27747
wrapped =3D <optimized out>
channel_start =3D <optimized out>
child_fd =3D <optimized out>
read_some_bytes =3D <optimized out>
nread =3D <optimized out>
leave =3D <optimized out>
nread =3D <optimized out>
p =3D <optimized out>
process_skipped =3D false
count =3D <optimized out>
__i =3D <optimized out>
__arr =3D <optimized out>
channel =3D <optimized out>
nfds =3D <optimized out>
Available =3D {
fds_bits =3D {0 <repeats 16 times>}
}
Writeok =3D {
fds_bits =3D {0 <repeats 16 times>}
}
check_write =3D <optimized out>
check_delay =3D <optimized out>
no_avail =3D <optimized out>
xerrno =3D 4
proc =3D <optimized out>
timeout =3D {
tv_sec =3D 22,
tv_nsec =3D 155939988
}
end_time =3D {
tv_sec =3D 18764,
tv_nsec =3D 580283828
}
timer_delay =3D <optimized out>
got_output_end_time =3D <optimized out>
wait =3D TIMEOUT
got_some_output =3D 4095
prev_wait_proc_nbytes_read =3D 0
retry_for_async =3D false
count =3D <optimized out>
last_read_channel =3D 14
MINIMUM =3D MINIMUM
TIMEOUT =3D TIMEOUT
FOREVER =3D FOREVER
#22 0x00005555555a66c6 in sit_for (timeout=3D<optimized out>, reading=3Dtru=
e, display_option=3D<optimized out>) at /home/reitero/build/sources/emacs/e=
macs_debug/src/dispnew.c:7006
sec =3D 30
nsec =3D 0
do_display =3D true
curbuf_eq_winbuf =3D true
nbytes =3D <optimized out>
#23 0x000055555568160b in read_char (commandflag=3D1, map=3D0x7fffe19522eb,=
prev_event=3D0x0, used_mouse_menu=3D0x7fffffffd6bb, end_time=3D0x0) at /ho=
me/reitero/build/sources/emacs/emacs_debug/src/keyboard.c:2942
tem0 =3D <optimized out>
timeout =3D 30
count1 =3D <optimized out>
delay_level =3D <optimized out>
buffer_size =3D <optimized out>
c =3D 0x0
local_getcjmp =3D {{
__jmpbuf =3D {0, 6663447910947144269, 0, 0, 0, 96, 666344791078=
3566413, 660911756749357645},
__mask_was_saved =3D 0,
__saved_mask =3D {
__val =3D {17862165311548904192, 59136, 3, 0, 140736997637280=
, 140737488344464, 93824993512082, 55832, 55832, 140737488344496, 938249935=
20386, 55832, 19175, 140737488344576, 93824993425632,=20
140737488344576}
}
}}
save_jump =3D {{
__jmpbuf =3D {0, 0, 0, 0, 0, 0, 0, 0},
__mask_was_saved =3D 0,
__saved_mask =3D {
__val =3D {0 <repeats 16 times>}
}
}}
tem =3D <optimized out>
save =3D <optimized out>
previous_echo_area_message =3D 0x0
also_record =3D 0x0
reread =3D false
recorded =3D false
polling_stopped_here =3D false
orig_kboard =3D 0x555555c736b0
jmpcount =3D <optimized out>
c_volatile =3D 0x0
#24 0x0000555555694a8e in read_key_sequence (keybuf=3D0x7fffffffd7e0, promp=
t=3D0x0, dont_downcase_last=3Dfalse, can_return_switch_frame=3Dtrue, fix_cu=
rrent_buffer=3Dtrue, prevent_redisplay=3Dfalse,=20
disable_text_conversion_p=3Dfalse) at /home/reitero/build/sources/emacs=
/emacs_debug/src/keyboard.c:11196
interrupted_kboard =3D 0x555555c736b0
k =3D <optimized out>
frame =3D <optimized out>
interrupted_frame =3D 0x7fffe374fd08
found =3D <optimized out>
key =3D <optimized out>
used_mouse_menu =3D false
last_real_key_start =3D 0
echo_local_start =3D 0
keys_local_start =3D 0
new_binding =3D <optimized out>
diff =3D <optimized out>
new_key =3D <optimized out>
done =3D <optimized out>
breakdown =3D <optimized out>
modifiers =3D <optimized out>
count =3D <optimized out>
t =3D 0
echo_start =3D 0
keys_start =3D 0
current_binding =3D 0x7fffe19522eb
first_unbound =3D 31
mock_input =3D 0
used_mouse_menu_history =3D {false <repeats 30 times>}
fkey =3D {
parent =3D 0x7fffe1dd2923,
map =3D 0x7fffe1dd2923,
start =3D 0,
end =3D 0
}
keytran =3D {
parent =3D 0x7fffe1c053cb,
map =3D 0x7fffe1c053cb,
start =3D 0,
end =3D 0
}
indec =3D {
parent =3D 0x7fffe1dd290b,
map =3D 0x7fffe1dd290b,
start =3D 0,
end =3D 0
}
shift_translated =3D false
delayed_switch_frame =3D 0x0
original_uppercase =3D 0x0
original_uppercase_position =3D -1
starting_buffer =3D 0x7fffe2c03ca0
fake_prefixed_keys =3D 0x0
first_event =3D 0x0
second_event =3D <optimized out>
#25 0x000055555567f427 in command_loop_1 () at /home/reitero/build/sources/=
emacs/emacs_debug/src/keyboard.c:1441
keybuf =3D {0xb2, 0x196, 0x196, 0x0, 0x7fffffffd820, 0x555555701c1d=
<NILP+33>, 0x0, 0x5555561975b0, 0x7fffffffd890, 0x55555570af67 <unbind_to+=
183>, 0xc, 0x13eb8, 0x38, 0x7fffe2961005, 0x7fffe1c017ec,=20
0xf7e328b68a2d5300, 0x7fffffffd890, 0x0, 0x7fffe3b70813, 0x0, 0x0=
, 0x55555567a06d <make_fixnum+17>, 0x7fffffffd910, 0x55555567cba5 <cmd_erro=
r+471>, 0x7fffffffd800, 0x7fffe1c06edb, 0x0, 0x0, 0x60,=20
0x55555570257c <SPECPDL_INDEX+30>}
i =3D <optimized out>
last_pt =3D <optimized out>
count =3D <optimized out>
symval =3D <optimized out>
cmd =3D <optimized out>
txt =3D <optimized out>
prev_modiff =3D 7060
prev_buffer =3D 0x7fffe2c03ca0
#26 0x0000555555702cbb in internal_condition_case (bfun=3D0x55555567f1ec <c=
ommand_loop_1>, handlers=3D<optimized out>, hfun=3D0x55555567c9ce <cmd_erro=
r>) at /home/reitero/build/sources/emacs/emacs_debug/src/eval.c:1713
val =3D <optimized out>
c =3D 0x555555b7cad0
#27 0x000055555567a1bc in command_loop_2 (handlers=3Dhandlers@entry=3D0xa8)=
at /home/reitero/build/sources/emacs/emacs_debug/src/keyboard.c:1180
val =3D <optimized out>
#28 0x0000555555702be1 in internal_catch (tag=3D<optimized out>, func=3D0x5=
5555567a19a <command_loop_2>, arg=3D0xa8) at /home/reitero/build/sources/em=
acs/emacs_debug/src/eval.c:1393
val =3D <optimized out>
c =3D 0x555555b7c940
#29 0x000055555567f067 in command_loop () at /home/reitero/build/sources/em=
acs/emacs_debug/src/keyboard.c:1158
No locals.
#30 0x000055555567f0f7 in recursive_edit_1 () at /home/reitero/build/source=
s/emacs/emacs_debug/src/keyboard.c:766
count =3D <optimized out>
val =3D <optimized out>
#31 0x0000555555682375 in Frecursive_edit () at /home/reitero/build/sources=
/emacs/emacs_debug/src/keyboard.c:849
count =3D <optimized out>
buffer =3D <optimized out>
#32 0x0000555555683714 in main (argc=3D<optimized out>, argv=3D0x7fffffffdb=
e8) at /home/reitero/build/sources/emacs/emacs_debug/src/emacs.c:2651
stack_bottom_variable =3D 0x7fffffffdbf8
old_argc =3D <optimized out>
dump_file =3D 0x0
no_loadup =3D false
junk =3D 0x0
dname_arg =3D 0x0
ch_to_dir =3D 0x0
original_pwd =3D 0x0
dump_mode =3D 0x0
skip_args =3D 0
temacs =3D 0x0
attempt_load_pdump =3D <optimized out>
only_version =3D false
rlim =3D {
rlim_cur =3D 10022912,
rlim_max =3D 18446744073709551615
}
lc_all =3D <optimized out>
sockfd =3D -1
module_assertions =3D <optimized out>
Lisp Backtrace:
"format-message" (0xffffcda8)
"timer-event-handler" (0xffffcf68)
In GNU Emacs 31.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.51, cairo version 1.18.4) of 2025-10-05 built on wilap
Repository revision: 67161c7fffb92d0ad05a47a303787d7c525a538e
Repository branch: feature/igc
System Description: Arch Linux
Configured using:
'configure 'CFLAGS=3D-g3 -ggdb -Og -mtune=3Dnative -march=3Dnative
-fno-omit-frame-pointer -fno-tree-sra -fno-inline' --prefix=3D/usr
--sysconfdir=3D/etc --libexecdir=3D/usr/lib --localstatedir=3D/var
--with-mps=3Dyes --with-gameuser=3Droot:games --with-pgtk --with-xft
--with-harfbuzz --with-modules --without-compress-install
--without-m17n-flt --with-libotf --without-imagemagick
--without-gsettings --without-gconf --with-native-compilation=3Daot
--with-tree-sitter --enable-link-time-optimization'
Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM HARFBUZZ JPEG LCMS2
LIBOTF LIBSYSTEMD LIBXML2 MODULES MPS NATIVE_COMP NOTIFY INOTIFY PDUMPER
PGTK PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS
TREE_SITTER WEBP XIM GTK3 ZLIB
Important settings:
value of $LANG: de_AT.UTF-8
locale-coding-system: utf-8-unix
--=-=-=--
Oliver Reiter <oliver.reiter@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#79584; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.