From unknown Tue Jun 17 01:49:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72802: 31.0.50; Crash in (equal sub-char-table-a sub-char-table-b) Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Aug 2024 13:15:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 72802 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 72802@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.172459167920824 (code B ref -1); Sun, 25 Aug 2024 13:15:02 +0000 Received: (at submit) by debbugs.gnu.org; 25 Aug 2024 13:14:39 +0000 Received: from localhost ([127.0.0.1]:42370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siD4o-0005Pm-Jp for submit@debbugs.gnu.org; Sun, 25 Aug 2024 09:14:39 -0400 Received: from lists.gnu.org ([209.51.188.17]:36974) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siD4m-0005Pe-GG for submit@debbugs.gnu.org; Sun, 25 Aug 2024 09:14:37 -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 ) id 1siD3y-0007qg-6y for bug-gnu-emacs@gnu.org; Sun, 25 Aug 2024 09:13:46 -0400 Received: from mail-4322.protonmail.ch ([185.70.43.22]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1siD3v-0000vy-R9 for bug-gnu-emacs@gnu.org; Sun, 25 Aug 2024 09:13:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1724591620; x=1724850820; bh=YRkZp7QPgIdk4DeGqhrLp+LtywdY336FZT600pP4J4M=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=Gc78WBpQIAAZiMeHj2WeoSXprMBMdGKQMw8RNt8zesGMP46ZNFCq53+VaLJYRAJ9L QY68eaFkrEP/vcD6SmDa+45llZLZSocfqdyCsQ5V3KYEFPpSftsSbE7VzjeRFiaxZ1 zkIWsNwZZWjo3dMedk6en9IlpvVG7X3t1gHdr3ngBVCKSF9HSGJwxvHAS2rD1TbNwu zhSDtxD5w6gf6Hz3RJJ14tDLvSohrauVA7xOirgnYpsF/GGwnMnOPk1tppb8LOQpNR 870/AMzmXIQcE3HfVlcirwqxKn5Y8leknCTf/NHOPZ7g8dcRYH/0UwdxOrHAAkZzsy y7pB7XLruC3YA== Date: Sun, 25 Aug 2024 13:13:34 +0000 From: Pip Cet Message-ID: <871q2c4uf6.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 9b9b8f2ca4acf3df0ee542e7e6f87d8c6a002129 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.43.22; envelope-from=pipcet@protonmail.com; helo=mail-4322.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Summary: Comparing sub char tables can lead to crashes in equal when they are read with their read syntax; using high-level char table manipulation routines and comparing char tables (not sub char tables directly) is almost certain to result in rare crashes as well. The code in internal_equal compares sub-char-tables incorrectly and segfaults on my machine (little-endian 64-bit words, LSB tags, 3 =3D=3D Lisp_Cons) when evaluating this code: (setq a #^^[3 2597376 (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (= 3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) = (3) (3) (3) (3) (3) (3) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2)= (2) (2) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3= ) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (= 3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) = (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3)= (3) (3)]) (setq b #^^[3 2597504 (3) (3) (3) (3) (2) (2) (2) (2) (2) (2) (2) (2) (2) (= 2) (2) (2) (2) (2) (2) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) = (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3)= (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3= ) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (3) (= 3) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) = (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2) (2)= (2) (2)]) (equal a b) This happened to me while working on pdumper code for the no-purespace branch and trying to compare dumped sub char tables, but it can happen when reading sub char tables using their read syntax, too. I'm almost certain the bug can actually happen when manipulating char tables using higher-level routines, and comparing char tables, not sub char tables. Comparing char tables definitely results in nonsensical (but identical) arguments 'o1' and 'o2' being passed to 'internal_equal', and put into the hash table 'ht' in internal_equal. This is almost definitely a crashable bug, but a very rare one (it relies on conservative stack marking marking our hash table and trying to mark the invalid conses in it), without using the read syntax for sub char tables. On 32-bit machines, the crashes might be much more common. The problem is this code: =09for (ptrdiff_t i =3D 0; i < size; i++) =09 { =09 Lisp_Object v1, v2; =09 v1 =3D AREF (o1, i); =09 v2 =3D AREF (o2, i); =09 if (!internal_equal (v1, v2, equal_kind, depth + 1, ht)) =09 return false; =09 } which assumes sub char tables are ordinary pseudovectors and can be compared by comparing XVECTOR (o1)->contents to XVECTOR (o2)->contents. However, sub char tables should be compared by comparing XSUB_CHAR_TABLE (o1)->contents to XSUB_CHAR_TABLE (o2)->contents, after checking that 'depth' and 'min_char' also match. The memory layout of sub char tables is: struct Lisp_Sub_Char_Table { /* HEADER.SIZE is the vector's size field, which also holds the pseudovector type information. It holds the size, too. */ union vectorlike_header header; /* Depth of this sub char-table. It should be 1, 2, or 3. A sub char-table of depth 1 contains 16 elements, and each element covers 4096 (128*32) characters. A sub char-table of depth 2 contains 32 elements, and each element covers 128 characters. A sub char-table of depth 3 contains 128 elements, and each element is for one character. */ int depth; /* Minimum character covered by the sub char-table. */ int min_char; /* Use set_sub_char_table_contents to set this. */ Lisp_Object contents[FLEXIBLE_ARRAY_MEMBER]; } GCALIGNED_STRUCT; So the first 64-bit word after the header has 'min_char' in the high bits, 3 in the low bits, in the above example. In my case, we end up calling internal_equal (o1=3DXIL(0x27a20000000003), o2=3DXIL(0x27a28000000003), equal_kind=3DEQUAL_PLAIN, depth=3D1, ht=3DXIL(0)) at fns.c:2887 with the nonsensical Lisp words o1 =3D 0x27a20000000003 (depth =3D 3, min_char =3D 0x27a200) and o2 =3D 0x27a28000000003 (depth =3D 3, min_char = =3D 0x27a280); these are interpreted as Lisp conses and we attempt to dereference them, which leads to the segfault. Relevant section of the backtrace: (gdb) bt full #0 0x0000555555838ea7 in internal_equal (o1=3DXIL(0x27a20000000003), o2=3D= XIL(0x27a28000000003), equal_kind=3DEQUAL_PLAIN, depth=3D1, ht=3DXIL(0)) at= fns.c:2887 li =3D { tortoise =3D XIL(0x27a20000000003), max =3D 2, n =3D 0, q =3D 2 } #1 0x00005555558393c8 in internal_equal (o1=3DXIL(0x555557718945), o2=3DXI= L(0x55555677bda5), equal_kind=3DEQUAL_PLAIN, depth=3D0, ht=3DXIL(0)) at fns= .c:2963 v1 =3D XIL(0x27a20000000003) v2 =3D XIL(0x27a28000000003) i =3D 0 size =3D 129 #2 0x0000555555838a01 in Fequal (o1=3DXIL(0x555557718945), o2=3DXIL(0x5555= 5677bda5)) at fns.c:2783 (gdb) l 2958=09=09for (ptrdiff_t i =3D 0; i < size; i++) 2959=09=09 { 2960=09=09 Lisp_Object v1, v2; 2961=09=09 v1 =3D AREF (o1, i); 2962=09=09 v2 =3D AREF (o2, i); 2963=09=09 if (!internal_equal (v1, v2, equal_kind, depth + 1, ht)) 2964=09=09 return false; 2965=09=09 } 2966=09=09return true; 2967=09 } (gdb) p SUB_CHAR_TABLE_P (o1) $38 =3D true (gdb) p SUB_CHAR_TABLE_P (o2) $39 =3D true (gdb) p *XSUB_CHAR_TABLE (o1) $40 =3D { header =3D { size =3D 4611686018981036161 }, depth =3D 3, min_char =3D 2597376, contents =3D 0x555557718950 } (gdb) p *XSUB_CHAR_TABLE (o2) $41 =3D { header =3D { size =3D 4611686018981036161 }, depth =3D 3, min_char =3D 2597504, contents =3D 0x55555677bdb0 } (gdb) p AREF (o1, 0) $42 =3D (struct Lisp_X *) 0x27a20000000003 (gdb) p AREF (o2, 0) $43 =3D (struct Lisp_X *) 0x27a28000000003 (gdb) p *XVECTOR (o1) $44 =3D { header =3D { size =3D 4611686018981036161 }, contents =3D 0x555557718948 } (gdb) p *XVECTOR (o2) $45 =3D { header =3D { size =3D 4611686018981036161 }, contents =3D 0x55555677bda8 } Fix coming up once this has a bug number. From unknown Tue Jun 17 01:49:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72802: 31.0.50; Crash in (equal sub-char-table-a sub-char-table-b) References: <871q2c4uf6.fsf@protonmail.com> In-Reply-To: <871q2c4uf6.fsf@protonmail.com> Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Aug 2024 14:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72802 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 72802@debbugs.gnu.org Received: via spool by 72802-submit@debbugs.gnu.org id=B72802.172459514129052 (code B ref 72802); Sun, 25 Aug 2024 14:13:02 +0000 Received: (at 72802) by debbugs.gnu.org; 25 Aug 2024 14:12:21 +0000 Received: from localhost ([127.0.0.1]:43104 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siDyf-0007YW-7W for submit@debbugs.gnu.org; Sun, 25 Aug 2024 10:12:21 -0400 Received: from mail-4316.protonmail.ch ([185.70.43.16]:59535) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siDyc-0007Y8-57 for 72802@debbugs.gnu.org; Sun, 25 Aug 2024 10:12:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1724595081; x=1724854281; bh=vhMxdBuTA99ucwdPPnVjWjQAaz4WBnZnkrrXWr7Wyi8=; h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date: Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector; b=XBJPpjJtRKidkGnwI5cTLVYRwHJeqJEJQlDWFeg9xbPqfM8YdSJUjzf7n283b4+ns JyRdbTZildeYVbHNf/exOS81h5EDV+Ro2ZdTuOSxFGkgtljMAEdUy8xtp4i9us/i2G nVm5oy5JOIyOJ1b0JYiAZnodeJztN238VzPWPPjWGisX7RLeizzWS8m2YPJdd0tPQk ZhxVpv+YbxV627Sp+ofHr6kox0TTXeQnDpjwKi058xXEEVXOj1SFb4zx5/7uRqoP7E 05Vsya8AEYTimnD0NUEWm62lvy1ZiGCYSaLJQ6Af1EH/oN2lVlXUWNGq04i5nRlcWs yl067vbM69mRA== Date: Sun, 25 Aug 2024 14:11:17 +0000 From: Pip Cet Message-ID: <87v7zo3d6m.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 6b1ff51a8c0184f0ea5b0aec039f58ada2e876a5 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > The code in internal_equal compares sub-char-tables incorrectly This patch should fix things for the release branch: >From df31249b3686c38e4816cfa2784c25443a61b749 Mon Sep 17 00:00:00 2001 From: Pip Cet Subject: [PATCH] Fix crashes when comparing sub char tables (Bug#72802) * src/fns.c (internal_equal): Handle sub char tables specially, like 'mark_char_table' does. --- src/fns.c | 16 +++++++++++++++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/src/fns.c b/src/fns.c index 57113a8c5ed..cb799a13a6e 100644 --- a/src/fns.c +++ b/src/fns.c @@ -2948,14 +2948,28 @@ internal_equal (Lisp_Object o1, Lisp_Object o2, enu= m equal_kind equal_kind, =09/* Aside from them, only true vectors, char-tables, compiled =09 functions, and fonts (font-spec, font-entity, font-object) =09 are sensible to compare, so eliminate the others now. */ +=09ptrdiff_t i =3D 0; =09if (size & PSEUDOVECTOR_FLAG) =09 { =09 if (((size & PVEC_TYPE_MASK) >> PSEUDOVECTOR_AREA_BITS) =09=09< PVEC_CLOSURE) =09 return false; + +=09 /* Bug#72802. See 'mark_char_table' in alloc.c. */ +=09 if (SUB_CHAR_TABLE_P (o1)) +=09 { +=09=09i =3D SUB_CHAR_TABLE_OFFSET; +=09=09if (XSUB_CHAR_TABLE (o1)->depth !=3D +=09=09 XSUB_CHAR_TABLE (o2)->depth) +=09=09 return false; +=09=09if (XSUB_CHAR_TABLE (o1)->min_char !=3D +=09=09 XSUB_CHAR_TABLE (o2)->min_char) +=09=09 return false; +=09 } + =09 size &=3D PSEUDOVECTOR_SIZE_MASK; =09 } -=09for (ptrdiff_t i =3D 0; i < size; i++) +=09for (; i < size; i++) =09 { =09 Lisp_Object v1, v2; =09 v1 =3D AREF (o1, i); --=20 2.45.2 Okay for emacs-30 (and/or master, though I'd prefer to fix it differently on that branch)? For the master branch, I think the right thing to do is to turn the first two, non-Lisp members of Lisp_Sub_Char_Table ('depth' and 'min_char') into 'Lisp_Object's. Then we can simplify the code and compare sub char tables as we do ordinary vectors, at the cost of eight bytes of extra storage per sub char table on machines with 64-bit EMACS_INTs. BTW, I'm surprised this code returns nil; I think that should be documented. (setq a (make-char-table nil)) (setq b (make-char-table nil)) (aset a 1 nil) (dotimes (i (max-char)) (unless (equal (aref a i) (aref b i)) (error "i =3D %S" i))) (equal a b) Pip From unknown Tue Jun 17 01:49:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72802: 31.0.50; Crash in (equal sub-char-table-a sub-char-table-b) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Aug 2024 14:52:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72802 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 72802@debbugs.gnu.org Received: via spool by 72802-submit@debbugs.gnu.org id=B72802.1724597495959 (code B ref 72802); Sun, 25 Aug 2024 14:52:01 +0000 Received: (at 72802) by debbugs.gnu.org; 25 Aug 2024 14:51:35 +0000 Received: from localhost ([127.0.0.1]:43145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siEad-0000FL-3r for submit@debbugs.gnu.org; Sun, 25 Aug 2024 10:51:35 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siEab-0000Ex-By for 72802@debbugs.gnu.org; Sun, 25 Aug 2024 10:51:34 -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 ) id 1siEZg-0005cx-Au; Sun, 25 Aug 2024 10:50:37 -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=BH4IGuCgdfm6DMYUn7bD4ulG6+2Y1vl8SkY58/m2F4E=; b=YXQYR+lwYCoo MGU2HZMommkq5VALSxXEEfZWYV57OPCdVkp+QlvjnI7ip8o6qwuy3JBcUTFZ7wBX5C3xYLFhvmtUy ynHE4x3HY6E3N1y0EzPYOfgR5JblKWJPnouCUWThCtztbzsIXovCevV/xf2vMlFeJmBuTOE1A0J0m TZteUI+lUoxOLufUUewA/VO210stao9MmbWUGjJhLcmlNEoahKIMueLb3vjARLQn4knFmeJztVBJ3 cXeevEu5TCuc3cTrYS6AtsaqSW/aCPXLFl1y4Rk+rfrAuCvtYrhhGKrK8qI+hvpktaOeRVkcqIyYz /aoeOVgW+1QMGVPi44ElKg==; Date: Sun, 25 Aug 2024 17:50:11 +0300 Message-Id: <86a5h0lkrg.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87v7zo3d6m.fsf@protonmail.com> (bug-gnu-emacs@gnu.org) References: <871q2c4uf6.fsf@protonmail.com> <87v7zo3d6m.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 25 Aug 2024 14:11:17 +0000 > From: Pip Cet via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Pip Cet writes: > > The code in internal_equal compares sub-char-tables incorrectly > > This patch should fix things for the release branch: I don't see a reason to install this on the release branch now. Not even on master, I think, unless we see a bug related to it that is not caused by a specially-concocted Lisp program or GDB command. If this is required for the no-pure-space branch, I think you should install this on that branch. Then it will be merged together with the branch. If you see some urgent need to fix this ASAP on master, please tell why you think so. > + /* Bug#72802. See 'mark_char_table' in alloc.c. */ > + if (SUB_CHAR_TABLE_P (o1)) > + { > + i = SUB_CHAR_TABLE_OFFSET; > + if (XSUB_CHAR_TABLE (o1)->depth != > + XSUB_CHAR_TABLE (o2)->depth) > + return false; > + if (XSUB_CHAR_TABLE (o1)->min_char != > + XSUB_CHAR_TABLE (o2)->min_char) > + return false; > + } I looked at mark_char_table, trying to understand what the above comments wants to say, and couldn't. So I think the comment should be improved, so that it would be more clear what it wants to say. Also, please move the assignment of SUB_CHAR_TABLE_OFFSET to i to after the two early 'return's. > For the master branch, I think the right thing to do is to turn the > first two, non-Lisp members of Lisp_Sub_Char_Table ('depth' and > 'min_char') into 'Lisp_Object's. Then we can simplify the code and > compare sub char tables as we do ordinary vectors, at the cost of eight > bytes of extra storage per sub char table on machines with 64-bit > EMACS_INTs. I'm not sure we want to pay this cost. What bothers me is mainly the run-time cost of extracting integers from Lisp objects. char-table is supposed to be very efficient, both memory-wise and CPU-wise, and I think the performance here trumps simplicity. > BTW, I'm surprised this code returns nil; I think that should be > documented. > > (setq a (make-char-table nil)) > (setq b (make-char-table nil)) > (aset a 1 nil) > (dotimes (i (max-char)) > (unless (equal (aref a i) (aref b i)) > (error "i = %S" i))) > (equal a b) Why are you surprised? Setting a single cell of a char-table changes its structure, usually in quite a radical way. 'aref' does some very special things for char-tables; the semantics of accessing an element of a vector is only correct superficially, not in the details. The internals of a char-table are not really documented in the ELisp manual; the description there is mostly phenomenological, without any details. If you want to document the internals, I think the proper place is to add a comment at the beginning of chartab.c with these details (and there are a lot of details not really documented anywhere, at least not explicitly), and then this nit should be part of that. From unknown Tue Jun 17 01:49:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72802: 31.0.50; Crash in (equal sub-char-table-a sub-char-table-b) Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Aug 2024 15:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72802 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 72802@debbugs.gnu.org Received: via spool by 72802-submit@debbugs.gnu.org id=B72802.17245989753575 (code B ref 72802); Sun, 25 Aug 2024 15:17:01 +0000 Received: (at 72802) by debbugs.gnu.org; 25 Aug 2024 15:16:15 +0000 Received: from localhost ([127.0.0.1]:43160 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siEyU-0000vb-Ip for submit@debbugs.gnu.org; Sun, 25 Aug 2024 11:16:15 -0400 Received: from mail-40131.protonmail.ch ([185.70.40.131]:48073) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siEyS-0000vL-Io for 72802@debbugs.gnu.org; Sun, 25 Aug 2024 11:16:13 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1724598916; x=1724858116; bh=cuJNGoyY2tWMbR6b5DyARVsEgUq9Pa+ABbE2GkaVvqU=; 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=xp1gXYXSkY6teerBy5cYJ/F5G76Svm0eDP2+FLscd+CcPkRLt+NNLoY1YIuecie5+ GJmOTl54//MXKBW69pTiVzzIDbaziRIrLGqkm6ymHo2xnRCrft0pYpv/3YsBwaixWi k9u8xndks2SCRbzsArBExcVEMT+HU5meeCWaX7HIywU4SUTOh/Jvd6CzkYie+OEHsJ wUgZ1nYRReLrcgZYOiyot/hsxkXW475+e9NjDtaI04pZxACUvbiiik4IHkmfDLTT/a ceDpdsME6vXCBd/Wk/P1aj92JcD8+W/rUj8SwQlfDlAvzPTrj9PwPNTh4pSwH8p+aX C+yrnXSkHfRDg== Date: Sun, 25 Aug 2024 15:15:14 +0000 From: Pip Cet Message-ID: <87le0k3a81.fsf@protonmail.com> In-Reply-To: <86a5h0lkrg.fsf@gnu.org> References: <871q2c4uf6.fsf@protonmail.com> <87v7zo3d6m.fsf@protonmail.com> <86a5h0lkrg.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 4edca4eff24f15817fbca113d31403b2f17e6236 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Date: Sun, 25 Aug 2024 14:11:17 +0000 >> From: Pip Cet via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> Pip Cet writes: >> > The code in internal_equal compares sub-char-tables incorrectly >> >> This patch should fix things for the release branch: > > I don't see a reason to install this on the release branch now. Your call. > Not even on master, I think, unless we see a bug related to it that is no= t > caused by a specially-concocted Lisp program or GDB command. It's a clear bug, whether or not the Lisp programs that cause it are "specially-concocted" (what's that supposed to mean, anyway? We can't just delay fixing what are clearly bugs until they pop up on random users' machines!) So I think it's important to fix this soon (not "now") on the master branch. > If this is required for the no-pure-space branch, I think you should > install this on that branch. Then it will be merged together with the > branch. It's not, it just popped up during work on that branch. > If you see some urgent need to fix this ASAP on master, please tell > why you think so. Not "ASAP", and not "urgent", no. We certainly can take the time to address your comments and fix up things. >> +=09 /* Bug#72802. See 'mark_char_table' in alloc.c. */ >> +=09 if (SUB_CHAR_TABLE_P (o1)) >> +=09 { >> +=09=09i =3D SUB_CHAR_TABLE_OFFSET; >> +=09=09if (XSUB_CHAR_TABLE (o1)->depth !=3D >> +=09=09 XSUB_CHAR_TABLE (o2)->depth) >> +=09=09 return false; >> +=09=09if (XSUB_CHAR_TABLE (o1)->min_char !=3D >> +=09=09 XSUB_CHAR_TABLE (o2)->min_char) >> +=09=09 return false; >> +=09 } > > I looked at mark_char_table, trying to understand what the above > comments wants to say, and couldn't. So I think the comment should > be improved, so that it would be more clear what it wants to say. As you will have seen, then, we compare the same "vector" elements in internal_equal as are marked in mark_char_table, but I agree the comment (and the code) can be improved, and will try to do that. > Also, please move the assignment of SUB_CHAR_TABLE_OFFSET to i to > after the two early 'return's. Gladly. >> For the master branch, I think the right thing to do is to turn the >> first two, non-Lisp members of Lisp_Sub_Char_Table ('depth' and >> 'min_char') into 'Lisp_Object's. Then we can simplify the code and >> compare sub char tables as we do ordinary vectors, at the cost of eight >> bytes of extra storage per sub char table on machines with 64-bit >> EMACS_INTs. > > I'm not sure we want to pay this cost. What bothers me is mainly the > run-time cost of extracting integers from Lisp objects. That might be noticeable on 32-bit machines with EMACS_WIDE_INT, I suppose, or on very old machines where memory isn't so much slower than register manipulation. > char-table is > supposed to be very efficient, both memory-wise and CPU-wise, and I > think the performance here trumps simplicity. How about using an "ordinary" pseudovector with its non-Lisp elements at the end? >> BTW, I'm surprised this code returns nil; I think that should be >> documented. >> >> (setq a (make-char-table nil)) >> (setq b (make-char-table nil)) >> (aset a 1 nil) >> (dotimes (i (max-char)) >> (unless (equal (aref a i) (aref b i)) >> (error "i =3D %S" i))) >> (equal a b) > > Why are you surprised? Setting a single cell of a char-table changes > its structure, usually in quite a radical way. 'aref' does some very > special things for char-tables; the semantics of accessing an element > of a vector is only correct superficially, not in the details. Indeed, and I expected (and still expect) 'equal' to ignore such details. > The internals of a char-table are not really documented in the ELisp > manual; the description there is mostly phenomenological, without any > details. I don't think 'equal' behavior is part of those "internals", and it certainly isn't a detail. Given the great trouble we're going to to make 'equal' work on char tables at all, I'm still surprised we didn't actually make it work the way it does on vectors. > If you want to document the internals, I think the proper Not the internals, just how 'equal' works. Pip From unknown Tue Jun 17 01:49:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72802: 31.0.50; Crash in (equal sub-char-table-a sub-char-table-b) Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Aug 2024 15:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72802 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Pip Cet Cc: 72802@debbugs.gnu.org Received: via spool by 72802-submit@debbugs.gnu.org id=B72802.17246004586066 (code B ref 72802); Sun, 25 Aug 2024 15:41:01 +0000 Received: (at 72802) by debbugs.gnu.org; 25 Aug 2024 15:40:58 +0000 Received: from localhost ([127.0.0.1]:43166 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siFMQ-0001Zm-7r for submit@debbugs.gnu.org; Sun, 25 Aug 2024 11:40:58 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siFMO-0001ZV-65 for 72802@debbugs.gnu.org; Sun, 25 Aug 2024 11:40:56 -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 ) id 1siFLT-0003SR-Kc; Sun, 25 Aug 2024 11:39:59 -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=Lxz8qYewWjU35Q/pvH9yM/kgFam9J6tcLvtrdxqP0oY=; b=jzgR5lVw1PeJ j83CUuaH7AJTSmUfjB2O7beYcBba2Zk5EQT/kWkBwoT/2LDFyyyUxh7YP27+HtdXKHZWGn5tPHgFd 6+vk8dOO6xq18ajUYfQ+x7LsQFi4WE48+OTNdDvnXd+FmLw3dQPo6jyNPvv9i1UL5IhtlrBwYCgy9 tba5yvVH9TLPZFWxu3fIZrYKQMO5egfMPvgUuY1YPJB6TVuAEf4s/Hs4zkOJbXEEGSLaX7zGyVmXj PhoGSPbwQwL6cQSGV35fBivt7iJZuNO0Y6FOUh1noZMDtSnkP/cSA9DbQVoi6V7lCVcrjPPJq8vAL K7xf6OSo0vMO4YekNYmOpQ==; Date: Sun, 25 Aug 2024 18:39:57 +0300 Message-Id: <868qwkligi.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87le0k3a81.fsf@protonmail.com> (message from Pip Cet on Sun, 25 Aug 2024 15:15:14 +0000) References: <871q2c4uf6.fsf@protonmail.com> <87v7zo3d6m.fsf@protonmail.com> <86a5h0lkrg.fsf@gnu.org> <87le0k3a81.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Sun, 25 Aug 2024 15:15:14 +0000 > From: Pip Cet > Cc: 72802@debbugs.gnu.org > > > Not even on master, I think, unless we see a bug related to it that is not > > caused by a specially-concocted Lisp program or GDB command. > > It's a clear bug, whether or not the Lisp programs that cause it are > "specially-concocted" (what's that supposed to mean, anyway? We can't > just delay fixing what are clearly bugs until they pop up on random > users' machines!) We certainly can, and do. Is there any code out there that compares char-tables and is affected by this? > So I think it's important to fix this soon (not "now") on the master > branch. I disagree, at least for now, sorry. char-tables have been stable for decades, so any change there should ideally be part of some significant enhancement that justifies the potential destabilization. Elimination of pure space or some similar change fits the bill. > > If this is required for the no-pure-space branch, I think you should > > install this on that branch. Then it will be merged together with the > > branch. > > It's not, it just popped up during work on that branch. Popped up how? In any case, there's nothing wrong with fixing that as part of a much larger changeset, which gives us significant gains. > > I'm not sure we want to pay this cost. What bothers me is mainly the > > run-time cost of extracting integers from Lisp objects. > > That might be noticeable on 32-bit machines with EMACS_WIDE_INT, I > suppose, or on very old machines where memory isn't so much slower than > register manipulation. > > > char-table is > > supposed to be very efficient, both memory-wise and CPU-wise, and I > > think the performance here trumps simplicity. > > How about using an "ordinary" pseudovector with its non-Lisp elements at > the end? Not even that, I think. Some of the char-table are accessed in the inner-most loops of the display code, and were at the time optimized especially for that purpose. I'm not interested in making changes there for minor simplifications. > >> BTW, I'm surprised this code returns nil; I think that should be > >> documented. > >> > >> (setq a (make-char-table nil)) > >> (setq b (make-char-table nil)) > >> (aset a 1 nil) > >> (dotimes (i (max-char)) > >> (unless (equal (aref a i) (aref b i)) > >> (error "i = %S" i))) > >> (equal a b) > > > > Why are you surprised? Setting a single cell of a char-table changes > > its structure, usually in quite a radical way. 'aref' does some very > > special things for char-tables; the semantics of accessing an element > > of a vector is only correct superficially, not in the details. > > Indeed, and I expected (and still expect) 'equal' to ignore such > details. No, 'equal' compares components literally. > > The internals of a char-table are not really documented in the ELisp > > manual; the description there is mostly phenomenological, without any > > details. > > I don't think 'equal' behavior is part of those "internals" Indeed, it isn't. But if the internals are described in enough detail, people will be able to understand why 'equal' returns nil in your case. > > If you want to document the internals, I think the proper > > Not the internals, just how 'equal' works. Why is it important? The doc string of 'equal' already says Return t if two Lisp objects have similar structure and contents. The two char-tables you are comparing have different structure, so 'equal' returns nil. What else would you like to document there? From unknown Tue Jun 17 01:49:43 2025 X-Loop: help-debbugs@gnu.org Subject: bug#72802: 31.0.50; Crash in (equal sub-char-table-a sub-char-table-b) Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Aug 2024 16:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 72802 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 72802@debbugs.gnu.org Received: via spool by 72802-submit@debbugs.gnu.org id=B72802.17246017368406 (code B ref 72802); Sun, 25 Aug 2024 16:03:02 +0000 Received: (at 72802) by debbugs.gnu.org; 25 Aug 2024 16:02:16 +0000 Received: from localhost ([127.0.0.1]:43176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siFh2-0002BW-0k for submit@debbugs.gnu.org; Sun, 25 Aug 2024 12:02:16 -0400 Received: from mail-4316.protonmail.ch ([185.70.43.16]:45405) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1siFgz-0002BJ-US for 72802@debbugs.gnu.org; Sun, 25 Aug 2024 12:02:15 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1724601677; x=1724860877; bh=yf77ONLWFrF6XJQylp0ypGeQAk2LOVyL64m6QDLSf1E=; 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=rCYfmQ576IC4Ua4e/PHsrt4Bvs5BMHiQuIAQVP4LNkBKxD8cRSS3YY5Gh2sp6fsv+ /md5Rq0/GDlAmbFUTepVTibman04F00V5YmnYQ9qRx39oZoERg+ESDcBe1Pjs/3pOs KGuR4OzAYEuZTPofQzbClndXXSak4OLZ8f+cvG6flXHvoUccMpzCG4VD7RC6q44esj d7crPdr/753bM/kDlzCESgSeNbcygNYWtCvhOzRl7HdNUmt47YXjhOdikBRR/Reo+e K6e+zT/krgus3GdibWNsedfCeBenZ6g7FZNGf4TcBDHwCGhN13gAOz+JOKmbAJlaA/ 2ooCJ9XEMYTGQ== Date: Sun, 25 Aug 2024 16:01:11 +0000 From: Pip Cet Message-ID: <87h6b8383f.fsf@protonmail.com> In-Reply-To: <868qwkligi.fsf@gnu.org> References: <871q2c4uf6.fsf@protonmail.com> <87v7zo3d6m.fsf@protonmail.com> <86a5h0lkrg.fsf@gnu.org> <87le0k3a81.fsf@protonmail.com> <868qwkligi.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 2244cac954fbda164ecf35530a896fe5e4794f6e MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> So I think it's important to fix this soon (not "now") on the master >> branch. > > I disagree, at least for now, sorry. Feel free to close this, then. From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 27 07:01:01 2024 Received: (at control) by debbugs.gnu.org; 27 Aug 2024 11:01:01 +0000 Received: from localhost ([127.0.0.1]:46100 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sitwb-0007uP-5W for submit@debbugs.gnu.org; Tue, 27 Aug 2024 07:01:01 -0400 Received: from sail-ipv4.us-core.com ([208.82.101.137]:45832) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1sitwY-0007uH-Pk for control@debbugs.gnu.org; Tue, 27 Aug 2024 07:00:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; s=2017; bh=+0FmcurLYZZXzm/ QBwlbRnXUg2N/8JwlNfM83pSOlww=; h=date:to:from; d=lease-up.com; b=R2LRd nd4OM6XSB+l6/oL4j9KAduWoHbTUu4OzH/Gjj3Y1v/RXWDd0rGrur2mbOx7iYzLS2HvPYU whGxVPz3qDGeehWd+ZTk5e/4ChT5bj+UUFHnjFQgXFe2zyMZYaGaTvG3NU1s5lw8c5kdLK tpfXZ1qxC7JyaUmfdzwlJxmNI8= Received: by sail-ipv4.us-core.com (OpenSMTPD) with ESMTPSA id 2ecf7c42 (TLSv1.3:TLS_CHACHA20_POLY1305_SHA256:256:NO) for ; Tue, 27 Aug 2024 11:00:04 +0000 (UTC) From: Felix Lechner To: control@debbugs.gnu.org Date: Tue, 27 Aug 2024 04:00:04 -0700 Message-ID: <8734mq5iyz.fsf@lease-up.com> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 2.0 (++) 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: close 72802 thanks Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record -0.0 SPF_PASS SPF: sender matches SPF record 1.8 MISSING_SUBJECT Missing Subject: header 0.2 NO_SUBJECT Extra score for no subject X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 1.0 (+) close 72802 thanks