From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 09 14:06:56 2020 Received: (at submit) by debbugs.gnu.org; 9 Feb 2020 19:06:56 +0000 Received: from localhost ([127.0.0.1]:53173 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j0rux-0002Rn-Us for submit@debbugs.gnu.org; Sun, 09 Feb 2020 14:06:56 -0500 Received: from lists.gnu.org ([209.51.188.17]:60654) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j0ruw-0002Rg-PC for submit@debbugs.gnu.org; Sun, 09 Feb 2020 14:06:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:53694) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j0ruu-0001dc-Ni for bug-gnu-emacs@gnu.org; Sun, 09 Feb 2020 14:06:53 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j0rus-00021n-P7 for bug-gnu-emacs@gnu.org; Sun, 09 Feb 2020 14:06:52 -0500 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:37143) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j0rur-0001tp-JL for bug-gnu-emacs@gnu.org; Sun, 09 Feb 2020 14:06:50 -0500 Received: by mail-wr1-x42f.google.com with SMTP id w15so4867323wru.4 for ; Sun, 09 Feb 2020 11:06:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version; bh=+q4WEFPO74VVuQdhOJ9rqZpmpk8y1ROSxVKnrOTsfdw=; b=bGOWmGMHZVVXRXxfo2egoXIb/lcl7QfGnbDOWvgdiFzOijfjpPHytFOGfNuVdS7oiT yd96sVyF1Kf6FzQTkwKRlJHWx1MLv/k4fHbLP6TGVEvDKoVkNCXuCJYUl2PsLmDey3Ek YbsDu01VxZLCtxtjlZCXMDQIYMTw+7Unp24qk1MMiCVp7sR9cxm9IJkr6v4n1Gjvhxgk I+TyWTt24PmYAPMgLQ+RbJ7VM1Hcgnr04Fr1QhcS8bbRv0D6dGvPQRfXfCXGS/RUFxqg bhS9+iuhoyfLaP616ko91+wpUVri7J9URBhqlpSavTi/YmXdX8FZoxvHhk/LMCWOyO0l /YbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version; bh=+q4WEFPO74VVuQdhOJ9rqZpmpk8y1ROSxVKnrOTsfdw=; b=OHTQbjefvmfJh/gHYx4Q7kJZ0O0GataU17MDrFHtHyZdM/8SclvCEsHWvvVpqH15gG uwUVxKHdpT2zFtDyuE145jL1FN9aqP1qT6Qa9iKKEw845iY10ekJJ87F0P3iuKxn3Ue2 hZgFt1aAnuszaDvAIylkAAqoyOtD4FH9VpkCJCvu11v2xUCeWzJ8iQ0bajFhA/2Afq+s tHXrN8OfFB9JhGIEsFR49S9h/yhtKtsH/DcHBs6pgvCBsUAIrz8cl4ny2PFoD93fPlcg y8TZUbXEUw3ctvU/1z1I3CgWbS4jv//U64KjnNjdwhlpU/q7wrGTlGqnnlOnB/SjZLu1 Eo2g== X-Gm-Message-State: APjAAAUO2cswBH+nvNNeUGfMJV03RalFuqNRZynemCZqDQvlXSwFTDIb dUx7aTh4RDAHC+gGLI38G1bYljD8 X-Google-Smtp-Source: APXvYqy2j4NVzrnberNCChUCYhgEmI4ni/6FFqH09hvcleLiHnHmJEx8MEr3PNgtC57eWySACUnPkA== X-Received: by 2002:a5d:4d4a:: with SMTP id a10mr12791575wru.220.1581275202156; Sun, 09 Feb 2020 11:06:42 -0800 (PST) Received: from lead ([2a02:8109:8ac0:2ff0:6c4d:15d5:57aa:7f1d]) by smtp.gmail.com with ESMTPSA id x10sm13147094wrp.58.2020.02.09.11.06.40 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 09 Feb 2020 11:06:41 -0800 (PST) From: Federico Tedin To: bug-gnu-emacs@gnu.org Subject: 28.0.50; Metahelp does not contain help text Date: Sun, 09 Feb 2020 20:06:40 +0100 Message-ID: <875zgf8trz.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::42f X-Spam-Score: 2.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: On Emacs 28.0.50 (5e7bead8ea), typing C-h C-h will display the *Metahelp* buffer, but instead of containing the usual help information, it will contain just the following: Automatically break line at a previous space, in insertion of text. Content analysis details: (2.3 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (federicotedin[at]gmail.com) -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at https://www.dnswl.org/, low trust [209.51.188.17 listed in list.dnswl.org] 2.0 SPOOFED_FREEMAIL No description available. X-Debbugs-Envelope-To: submit 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: -0.7 (/) On Emacs 28.0.50 (5e7bead8ea), typing C-h C-h will display the *Metahelp* buffer, but instead of containing the usual help information, it will contain just the following: Automatically break line at a previous space, in insertion of text. (which appears to be the document string for `auto-fill-function' in simple.el). From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 09 14:23:16 2020 Received: (at 39529) by debbugs.gnu.org; 9 Feb 2020 19:23:16 +0000 Received: from localhost ([127.0.0.1]:53179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j0sAm-0002op-CM for submit@debbugs.gnu.org; Sun, 09 Feb 2020 14:23:16 -0500 Received: from eggs.gnu.org ([209.51.188.92]:40596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j0sAk-0002od-Pk for 39529@debbugs.gnu.org; Sun, 09 Feb 2020 14:23:15 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33326) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1j0sAf-0007GK-MT; Sun, 09 Feb 2020 14:23:09 -0500 Received: from [176.228.60.248] (port=3841 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1j0sAf-0001sj-53; Sun, 09 Feb 2020 14:23:09 -0500 Date: Sun, 09 Feb 2020 21:22:54 +0200 Message-Id: <83d0and0q9.fsf@gnu.org> From: Eli Zaretskii To: Federico Tedin In-reply-to: <875zgf8trz.fsf@gmail.com> (message from Federico Tedin on Sun, 09 Feb 2020 20:06:40 +0100) Subject: Re: bug#39529: 28.0.50; Metahelp does not contain help text References: <875zgf8trz.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 39529 Cc: 39529@debbugs.gnu.org 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.7 (-) > From: Federico Tedin > Date: Sun, 09 Feb 2020 20:06:40 +0100 > > On Emacs 28.0.50 (5e7bead8ea), typing C-h C-h will display the > *Metahelp* buffer, but instead of containing the usual help information, > it will contain just the following: > > Automatically break line at a previous space, in insertion of text. It's related to dumping in some way, because in temacs this works as expected. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 09 14:35:05 2020 Received: (at 39529) by debbugs.gnu.org; 9 Feb 2020 19:35:05 +0000 Received: from localhost ([127.0.0.1]:53188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j0sMC-00037O-S9 for submit@debbugs.gnu.org; Sun, 09 Feb 2020 14:35:05 -0500 Received: from eggs.gnu.org ([209.51.188.92]:42162) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j0sMA-00036r-Ra for 39529@debbugs.gnu.org; Sun, 09 Feb 2020 14:35:03 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:33395) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1j0sM5-00042Y-3Y; Sun, 09 Feb 2020 14:34:57 -0500 Received: from [176.228.60.248] (port=4557 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1j0sM4-00040S-E3; Sun, 09 Feb 2020 14:34:56 -0500 Date: Sun, 09 Feb 2020 21:34:40 +0200 Message-Id: <83blq7d06n.fsf@gnu.org> From: Eli Zaretskii To: federicotedin@gmail.com, Paul Eggert In-reply-to: <83d0and0q9.fsf@gnu.org> (message from Eli Zaretskii on Sun, 09 Feb 2020 21:22:54 +0200) Subject: Re: bug#39529: 28.0.50; Metahelp does not contain help text References: <875zgf8trz.fsf@gmail.com> <83d0and0q9.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 39529 Cc: 39529@debbugs.gnu.org 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.7 (-) > Date: Sun, 09 Feb 2020 21:22:54 +0200 > From: Eli Zaretskii > Cc: 39529@debbugs.gnu.org > > > From: Federico Tedin > > Date: Sun, 09 Feb 2020 20:06:40 +0100 > > > > On Emacs 28.0.50 (5e7bead8ea), typing C-h C-h will display the > > *Metahelp* buffer, but instead of containing the usual help information, > > it will contain just the following: > > > > Automatically break line at a previous space, in insertion of text. > > It's related to dumping in some way, because in temacs this works as > expected. I suspect the sxhash changes on Jan 7. This problem started happening in that day's build. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 15 18:25:57 2020 Received: (at 39529-done) by debbugs.gnu.org; 15 Feb 2020 23:25:57 +0000 Received: from localhost ([127.0.0.1]:36585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j36ov-0003zc-4M for submit@debbugs.gnu.org; Sat, 15 Feb 2020 18:25:57 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52444) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j36ot-0003zO-EL for 39529-done@debbugs.gnu.org; Sat, 15 Feb 2020 18:25:56 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 961021600AF; Sat, 15 Feb 2020 15:25:49 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4IwSJrtLApRi; Sat, 15 Feb 2020 15:25:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 97CBA1600B2; Sat, 15 Feb 2020 15:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qjt1PlSCcD2J; Sat, 15 Feb 2020 15:25:48 -0800 (PST) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 56C3F1600AF; Sat, 15 Feb 2020 15:25:48 -0800 (PST) Subject: Re: bug#39529: 28.0.50; Metahelp does not contain help text To: Eli Zaretskii References: <875zgf8trz.fsf@gmail.com> <83d0and0q9.fsf@gnu.org> <83blq7d06n.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Sat, 15 Feb 2020 15:25:44 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: <83blq7d06n.fsf@gnu.org> Content-Type: multipart/mixed; boundary="------------BB186750EA64155729615E92" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 39529-done Cc: 39529-done@debbugs.gnu.org, federicotedin@gmail.com 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 (---) This is a multi-part message in MIME format. --------------BB186750EA64155729615E92 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/9/20 11:34 AM, Eli Zaretskii wrote: > I suspect the sxhash changes on Jan 7. This problem started happening > in that day's build. Right you are. The problem was Emacs was using a hash table to unify identical Lisp compiled objects when purecopying them, even though their doc strings were not set up yet (and so were 0 placeholders that always compared equal). Formerly this bug was masked because sxhash simply returned the objects' hashed addresses, but the January 7 changes unveiled the bug. I install the attached patch to fix the problem. --------------BB186750EA64155729615E92 Content-Type: text/x-patch; charset=UTF-8; name="0001-Fix-C-h-C-h-bug-due-to-mutating-a-hash-key.patch" Content-Disposition: attachment; filename="0001-Fix-C-h-C-h-bug-due-to-mutating-a-hash-key.patch" Content-Transfer-Encoding: quoted-printable >From 3480071dfab30eaca7f1d014600b864d2ea22f62 Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sat, 15 Feb 2020 15:12:34 -0800 Subject: [PATCH] Fix C-h C-h bug due to mutating a hash key MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit Problem reported by Federico Tedin (Bug#39529). The problem was that dumping uses a hash table based on 'equal' when purecopying compiled objects, but then modifies the compiled objects while they are keys in the table. This no-no was uncovered by the sxhash fixes in 2020-01-07T19:23:11Z!eggert@cs.ucla.edu. Eli Zaretski pinpointed the patch that triggered the bug. * src/lread.c (read1): When reading a compiled object, replace its docstring with a unique negative integer instead of with 0, so that purecopy doesn=E2=80=99t unify it with some other compiled object that happens to have the same Lisp code. --- src/lread.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+) diff --git a/src/lread.c b/src/lread.c index c124d5a1d8..f39e81ae2c 100644 --- a/src/lread.c +++ b/src/lread.c @@ -2974,6 +2974,21 @@ read1 (Lisp_Object readcharfun, int *pch, bool fir= st_in_list) vec =3D XVECTOR (tmp); if (vec->header.size =3D=3D 0) invalid_syntax ("Empty byte-code object"); + + if (COMPILED_DOC_STRING < vec->header.size + && AREF (tmp, COMPILED_DOC_STRING) =3D=3D make_fixnum (0)) + { + /* read_list found a docstring like '(#$ . 5521)' and treated it + as 0. This placeholder 0 would lead to accidental sharing in + purecopy's hash-consing, so replace it with a (hopefully) + unique integer placeholder, which is negative so that it is + not confused with a DOC file offset. Eventually + Snarf-documentation should replace the placeholder with the + actual docstring. */ + EMACS_UINT hash =3D XHASH (tmp) | (INTMASK - INTMASK / 2); + ASET (tmp, COMPILED_DOC_STRING, make_ufixnum (hash)); + } + make_byte_code (vec); return tmp; } --=20 2.17.1 --------------BB186750EA64155729615E92-- From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 16 10:35:42 2020 Received: (at 39529) by debbugs.gnu.org; 16 Feb 2020 15:35:42 +0000 Received: from localhost ([127.0.0.1]:37580 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j3LxO-0008Gw-0B for submit@debbugs.gnu.org; Sun, 16 Feb 2020 10:35:42 -0500 Received: from eggs.gnu.org ([209.51.188.92]:53226) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j3LxL-0008Gi-Hx for 39529@debbugs.gnu.org; Sun, 16 Feb 2020 10:35:40 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]:36474) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1j3LxG-00081V-2U; Sun, 16 Feb 2020 10:35:34 -0500 Received: from [176.228.60.248] (port=4207 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1j3LxE-0005AX-4Z; Sun, 16 Feb 2020 10:35:33 -0500 Date: Sun, 16 Feb 2020 17:35:43 +0200 Message-Id: <83pneemto0.fsf@gnu.org> From: Eli Zaretskii To: Paul Eggert In-reply-to: (message from Paul Eggert on Sat, 15 Feb 2020 15:25:44 -0800) Subject: Re: bug#39529: 28.0.50; Metahelp does not contain help text References: <875zgf8trz.fsf@gmail.com> <83d0and0q9.fsf@gnu.org> <83blq7d06n.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 39529 Cc: 39529@debbugs.gnu.org, federicotedin@gmail.com 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.7 (-) > Cc: federicotedin@gmail.com, 39529-done@debbugs.gnu.org > From: Paul Eggert > Date: Sat, 15 Feb 2020 15:25:44 -0800 > > > I suspect the sxhash changes on Jan 7. This problem started happening > > in that day's build. > > Right you are. The problem was Emacs was using a hash table to unify identical > Lisp compiled objects when purecopying them, even though their doc strings were > not set up yet (and so were 0 placeholders that always compared equal). Formerly > this bug was masked because sxhash simply returned the objects' hashed > addresses, but the January 7 changes unveiled the bug. I install the attached > patch to fix the problem. Thanks, the problem is gone now. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 16 11:52:22 2020 Received: (at 39529) by debbugs.gnu.org; 16 Feb 2020 16:52:22 +0000 Received: from localhost ([127.0.0.1]:37623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j3N9Z-0001bc-UB for submit@debbugs.gnu.org; Sun, 16 Feb 2020 11:52:22 -0500 Received: from mail-oi1-f176.google.com ([209.85.167.176]:34980) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j3N9X-0001bK-Sn; Sun, 16 Feb 2020 11:52:20 -0500 Received: by mail-oi1-f176.google.com with SMTP id b18so14499388oie.2; Sun, 16 Feb 2020 08:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xef/rt+P0JDwUbA1iZHqaYqVW90Aww50YQfMct54sP0=; b=Svptg56GmJml9fvVlwX3HMkkdvCQd8K8jK7FnRQzqnS/cltsf66Py+Q7gUBi++Q7xb Z+gJzerUydQTIv8gYgpwE+tyUXbftciyV5pteRq00/bTWscFwImMajF9MKK9C7lFkAkn WAxIFSxPjojYiOeor5wBgRi6wNcpFsg7tPDxDGl2F+qI1m34SqHLqreNd6ajMbHsYH/g JpaZYzdryjlEXZkKsEM8KniABNdapnAkHqDjr2dW4IMs4m7z2A9Fw3MOSMozC1Tn67Yx zJKn5rEizXa6ZEfLwJ+Ci5CwtHG+zWwpzZvN89MjlcCd2B0275cM1EPpn5u7CSBrDog9 yZfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xef/rt+P0JDwUbA1iZHqaYqVW90Aww50YQfMct54sP0=; b=VMpQb1nOGaE71DuZMxzeugiO1c0G5I6lkGp9/MGWl1+XRBxo4XT5rYIN/8mFG7g/uu GD3lBh0v7Rr49SkatngOKLlJ4ce8BY8DXr9/ZAfaW51JWFTiZATmI577UahI8goeDRsV hNsAkzAJOp1tHrfvGm+7cyXGb36Nld90ZHQ56BLWY6nlgKd8Ezpa5ufc4eXo/Gr8tFsz 9DlVz+CBmuJ+r+9gJ2ETP4bLmrkIf5xLmbLeno6nVxctzuiwlN3j0RdvFYxaLmVMB4Ri 23cDIgS7ZTbIBa4vBBW7mHFKFE4pJZ6EmB8Mlt9ZsEjCLhAzATNCPn3Vrr5F8oKtjLvo vlIQ== X-Gm-Message-State: APjAAAWtVqz9u1f0/Cbc71/DlKsWdzHUhP1JZ9cEz6IUJtILXAH0Jz2z GoNs8SUmEovG/FhduQPbXLkA80AwXXDEQIIsQenvysRQ X-Google-Smtp-Source: APXvYqxHtKnY4Fi26W42cGPSYhBofK4+hui03FNi99Pk9pqNe2h6qegKs+U7bBSTnFJFwu3OVafgLYO9cG5Q316dwJg= X-Received: by 2002:aca:5588:: with SMTP id j130mr7441003oib.122.1581871933902; Sun, 16 Feb 2020 08:52:13 -0800 (PST) MIME-Version: 1.0 References: <875zgf8trz.fsf@gmail.com> <83d0and0q9.fsf@gnu.org> <83blq7d06n.fsf@gnu.org> In-Reply-To: From: Pip Cet Date: Sun, 16 Feb 2020 16:51:38 +0000 Message-ID: Subject: Re: bug#39529: 28.0.50; Metahelp does not contain help text To: 39529@debbugs.gnu.org, eggert@cs.ucla.edu, federicotedin@gmail.com Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 39529 Cc: Eli Zaretskii , 39529-done@debbugs.gnu.org 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 (-) On Sat, Feb 15, 2020 at 11:26 PM Paul Eggert wrote: > > I suspect the sxhash changes on Jan 7. This problem started happening > > in that day's build. > > Right you are. The problem was Emacs was using a hash table to unify identical > Lisp compiled objects when purecopying them, even though their doc strings were > not set up yet (and so were 0 placeholders that always compared equal). Formerly > this bug was masked because sxhash simply returned the objects' hashed > addresses, but the January 7 changes unveiled the bug. I install the attached > patch to fix the problem. That works as a quick fix, but it's not perfectly correct, since it relies on different objects having different hashes, and they might, by pure chance, have the same hash. We need to fix the underlying issue, or at least go for the correct "quick fix", which is to make equal = eq for bytecode objects (this is almost indistinguishable from the previous behavior, before sxhash-equal was "fixed"). The pure-cons hash, and many other places, assume "equal" means "equivalent" in some way. That's not true for bytecode objects, where a function always returning `nil' can be equal to one always returning `t'. And I still suspect many other people have made the same "mistake" as I, of assuming the previous behavior of equal-based hashes for markers and overlays was guaranteed. To recap, the January 7 changes broke code that uses markers or overlays as hash keys (or as components of hash keys) in equal-based hash tables; before the changes, it was safe to do so. After the changes, it's only safe to do if the character positions don't change between storage and lookup, and there's no hint at what might be happening. In summary, I still think the right fix is not to make equal look at more state than sxhash-equal used to, particularly for Emacs 27. We've now seen that the January 7 changes cause follow-up bugs, such as this one, so maybe it's time to reconsider what the right thing to do is here. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 16 14:43:59 2020 Received: (at 39529) by debbugs.gnu.org; 16 Feb 2020 19:43:59 +0000 Received: from localhost ([127.0.0.1]:37730 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j3Ppf-0005dW-DA for submit@debbugs.gnu.org; Sun, 16 Feb 2020 14:43:59 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:59394) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j3Ppd-0005dF-8A for 39529@debbugs.gnu.org; Sun, 16 Feb 2020 14:43:58 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 8AD4516008E; Sun, 16 Feb 2020 11:43:51 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id BZpX6rgIcPdK; Sun, 16 Feb 2020 11:43:50 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 9277E160093; Sun, 16 Feb 2020 11:43:50 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id qGgRx-U7UNAH; Sun, 16 Feb 2020 11:43:50 -0800 (PST) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 5FE9B16008E; Sun, 16 Feb 2020 11:43:50 -0800 (PST) Subject: Re: bug#39529: 28.0.50; Metahelp does not contain help text To: Pip Cet References: <875zgf8trz.fsf@gmail.com> <83d0and0q9.fsf@gnu.org> <83blq7d06n.fsf@gnu.org> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: <59be714f-1b52-a068-70c8-3204cf016ca2@cs.ucla.edu> Date: Sun, 16 Feb 2020 11:43:50 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------CA5EC3F59ADFDE5A87B1BC71" Content-Language: en-US X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 39529 Cc: 39529@debbugs.gnu.org, Eli Zaretskii , federicotedin@gmail.com 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 (---) This is a multi-part message in MIME format. --------------CA5EC3F59ADFDE5A87B1BC71 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 2/16/20 8:51 AM, Pip Cet wrote: > it relies on different objects having different hashes, and they might, > by pure chance, have the same hash. That could happen only if two Lisp vector addresses disagree only in the high-order bit during dumping while on a USE_LSB_TAG platform, something that I didn't think possible on practical Emacs targets. However, the potential problem is easy enough to work around; I installed the attached. > We need to fix the underlying issue, or at least go for the correct > "quick fix", which is to make equal = eq for bytecode objects (this is > almost indistinguishable from the previous behavior, before > sxhash-equal was "fixed"). Give the attached patch I hope no such quick fix is needed. For what it's worth, the patched code is similar to what Fautoload does; so if there's something wrong here, a similar wrongness has likely been present in Fautoload for some time. > The pure-cons hash, and many other places, assume "equal" means > "equivalent" in some way. That's not true for bytecode objects, where > a function always returning `nil' can be equal to one always returning > `t'. Could you give an example of this? When I byte-compiled this: (defun always-t () t) (defun always-nil () nil) the .elc file had different bytecode objects #[nil "\300\207" [t] 1] and #[nil "\300\207" [nil] 1]. (The strings are the same, but that's not the issue here.) > the right fix is not to make equal look at > more state than sxhash-equal used to, particularly for Emacs 27. That would indeed make 'equal' and 'sxhash-equal' consistent. But wouldn't it potentially break a different set of user programs, that (say) rely on 'equal' returning nil when markers point to different locations? So I'd be leery about messing with Emacs 27 in this area. For the master branch, it's more of a question of what 'equal' should mean. Obviously 'sxhash-equal' must be consistent with 'equal'. If we decide that 'equal' should not inspect marker contents etc., then we should change 'sxhash-equal' accordingly. (To my mind a better fix would be to introduce the notion of immutability, and for sxhash-equal to inspect only the immutable parts of key contents. But now it's time for me to duck and run....) --------------CA5EC3F59ADFDE5A87B1BC71 Content-Type: text/x-patch; charset=UTF-8; name="0001-Improve-C-h-C-h-bug-fix.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Improve-C-h-C-h-bug-fix.patch" >From 556cc727e5076d590f8286406e4f46cff3cee41e Mon Sep 17 00:00:00 2001 From: Paul Eggert Date: Sun, 16 Feb 2020 11:36:19 -0800 Subject: [PATCH] Improve C-h C-h bug fix * src/lread.c (read1): Guard against two 'struct Lisp_Vector *' pointers differing only in their most significant bit. Problem reported by Pip Cet (Bug#39529#22). --- src/lread.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/src/lread.c b/src/lread.c index 1613719eb1..70984d37e1 100644 --- a/src/lread.c +++ b/src/lread.c @@ -2982,10 +2982,13 @@ read1 (Lisp_Object readcharfun, int *pch, bool first_in_list) as 0. This placeholder 0 would lead to accidental sharing in purecopy's hash-consing, so replace it with a (hopefully) unique integer placeholder, which is negative so that it is - not confused with a DOC file offset. Eventually - Snarf-documentation should replace the placeholder with the - actual docstring. */ - EMACS_UINT hash = XHASH (tmp) | (INTMASK - INTMASK / 2); + not confused with a DOC file offset (the USE_LSB_TAG shift + relies on the fact that VALMASK is one bit narrower than + INTMASK). Eventually Snarf-documentation should replace the + placeholder with the actual docstring. */ + verify (INTMASK & ~VALMASK); + EMACS_UINT hash = ((XHASH (tmp) >> USE_LSB_TAG) + | (INTMASK - INTMASK / 2)); ASET (tmp, COMPILED_DOC_STRING, make_ufixnum (hash)); } -- 2.17.1 --------------CA5EC3F59ADFDE5A87B1BC71-- From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 14:57:42 2020 Received: (at 39529) by debbugs.gnu.org; 18 Feb 2020 19:57:42 +0000 Received: from localhost ([127.0.0.1]:41309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4902-0002d9-CG for submit@debbugs.gnu.org; Tue, 18 Feb 2020 14:57:42 -0500 Received: from mail-ot1-f50.google.com ([209.85.210.50]:45090) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4901-0002cx-9F for 39529@debbugs.gnu.org; Tue, 18 Feb 2020 14:57:41 -0500 Received: by mail-ot1-f50.google.com with SMTP id 59so20764595otp.12 for <39529@debbugs.gnu.org>; Tue, 18 Feb 2020 11:57:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/QYaqtjw6WWWB635Z4aqbETkmqB1KZlRU8z9KEgGXoE=; b=CQeyCk5UKvuFvuSG+LNRXPLBrGY0EeBSauAuijFWv31rNcrR4NMQ9uDi4yfP3frhkq jkhcbbCylWDboAQJM77DCctASeYjllGQpG+Od/5tkFLyDWdsIQsRNgTRAJZrLu0irTMc mYR5YKMK4bmLxEdI6QQYUWFlnbgmQikqc17VlrL879fVhV2PJGNdxVUL6q6DS4AJlQpg cTfxDSTGCQjVCJF3gxGU1ZBK16y6INN7F91YFgAfZCO10Qq8qth5B5wCYq8SHP1xbLrz csD1HiXZGpqNI71thuRgUu2rsQQS55MdtHh1g4AK3746XEiWiIxa6di2kXOk76bEVIxv +xxw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/QYaqtjw6WWWB635Z4aqbETkmqB1KZlRU8z9KEgGXoE=; b=MDjDnwlPOodyDJpKDPLXigOUBjTcyhRWS77kmNd5ZmpOclbSpj4Qh6PVbqtDyJj7oC cz2myQIGAfwKDtJcrGxjrOm0UAF/nGrRHQG/l6Cn9UO8B28MMf1w4T18dxo9EgGHULm9 UPWNx4BnmGmqkU2ZPKB+M8pTpT/Gy3d84C9v+rPjTsGYuxEMaobkLOXAQjl3euDlTOpN Cy89bu42omhkPCBpAOLWPys7qR25FEZliBw+d5OQ+Hok6BPHr0dA+rD7sz9bVwF3Rmuz rDBY2Zg/B3giC00rztBSrGg3OepHOmQ7QhEm0O7+dI3PmfUxOS/X0jN5DV8cxPMlYtWv sXDg== X-Gm-Message-State: APjAAAUktBxsnFzyiSNZQJ5ahMr/NdMLHQ/BFFV/WMagX80/jectfwTC yM8UiGWXe7AMJwaCYTwJON+6tkfmosN1dJc4NXw= X-Google-Smtp-Source: APXvYqxD/iNP9tHnvaE34sik/8SXRPICIj8ALeIhqMwpibWA94SbaOLVPv81Z23TiCse+NpwTxWO+4b25+vLzZIdipA= X-Received: by 2002:a9d:1c9c:: with SMTP id l28mr16565546ota.210.1582055855584; Tue, 18 Feb 2020 11:57:35 -0800 (PST) MIME-Version: 1.0 References: <875zgf8trz.fsf@gmail.com> <83d0and0q9.fsf@gnu.org> <83blq7d06n.fsf@gnu.org> <59be714f-1b52-a068-70c8-3204cf016ca2@cs.ucla.edu> In-Reply-To: <59be714f-1b52-a068-70c8-3204cf016ca2@cs.ucla.edu> From: Pip Cet Date: Tue, 18 Feb 2020 19:56:59 +0000 Message-ID: Subject: Re: bug#39529: 28.0.50; Metahelp does not contain help text To: Paul Eggert Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 39529 Cc: 39529@debbugs.gnu.org, Eli Zaretskii , federicotedin@gmail.com 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 (-) On Sun, Feb 16, 2020 at 7:43 PM Paul Eggert wrote: > On 2/16/20 8:51 AM, Pip Cet wrote: > > it relies on different objects having different hashes, and they might, > > by pure chance, have the same hash. Just to be clear about that: I was wrong here, and had misread the code. It does not, in fact, rely on arbitrary different objects having different hashes; it relies on different vectors having different XHASHes, which you correctly point out they do, on practical targets. > That could happen only if two Lisp vector addresses disagree only in the > high-order bit during dumping while on a USE_LSB_TAG platform, something that I > didn't think possible on practical Emacs targets. However, the potential problem > is easy enough to work around; I installed the attached. You're absolutely correct. > > We need to fix the underlying issue, or at least go for the correct > > "quick fix", which is to make equal = eq for bytecode objects (this is > > almost indistinguishable from the previous behavior, before > > sxhash-equal was "fixed"). > > Give the attached patch I hope no such quick fix is needed. Let me turn around that argument: if we rely on the precise definitions of XHASH etc. that were in place prior to the January changes, no "quick fix" was needed; it was simply the case that the predicate used by hash tables created with :test equal diverged from the built-in `equal' predicate in one more way than was already documented. (Those documented deviations are that mutations of hash keys won't cause rehashing, and that equal will sometimes signal for (equal a b) but not for (equal b a)). > For what it's worth, the patched code is similar to what Fautoload does; so if > there's something wrong here, a similar wrongness has likely been present in > Fautoload for some time. Thanks for pointing that out, I wasn't aware of it. > > The pure-cons hash, and many other places, assume "equal" means > > "equivalent" in some way. That's not true for bytecode objects, where > > a function always returning `nil' can be equal to one always returning > > `t'. > > Could you give an example of this? When I byte-compiled this: (defun f () (let ((x '(#1=(nil) . #1#))) (eq (car x) (cdr x)))) (defun g () (let ((x '((nil) . (nil))) (eq (car x) (cdr x)))) That's somewhat contrived; more realistic examples where this might actually be a problem would use string properties. > > the right fix is not to make equal look at > > more state than sxhash-equal used to, particularly for Emacs 27. > > That would indeed make 'equal' and 'sxhash-equal' consistent. But wouldn't it > potentially break a different set of user programs, that (say) rely on 'equal' > returning nil when markers point to different locations? You're right, that wouldn't work. I'll propose one more thing, which sounds horrible at first but might be the least horrible option: accept that `equal', the function, and `:test equal', the hash table predicate, have diverged significantly already. Keep them separate but similar in Emacs 27, and introduce more useful hash table predicates in Emacs 28. That would allow us to restore the previous behavior for Emacs 27, document the inconsistency there, fix the pdumper bug that caused the original bug report, remove the hacky XHASH implementation dependency from Fautoload and read1, and return to cleaner semantics for Emacs 28. > So I'd be leery about messing with Emacs 27 in this area. I think we already have messed with Emacs 27 in ways that we shouldn't have. > (To my mind a better fix would be to introduce the notion of immutability, and > for sxhash-equal to inspect only the immutable parts of key contents. But now > it's time for me to duck and run....) immutably-equal would indeed be one hash table predicate that I'd like to see. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 20:22:08 2020 Received: (at 39529) by debbugs.gnu.org; 19 Feb 2020 01:22:08 +0000 Received: from localhost ([127.0.0.1]:41490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4E3z-0002LA-Qz for submit@debbugs.gnu.org; Tue, 18 Feb 2020 20:22:08 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:52834) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4E3x-0002Ke-CP for 39529@debbugs.gnu.org; Tue, 18 Feb 2020 20:22:06 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id CC6461600AB; Tue, 18 Feb 2020 17:21:59 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id eafC2Yk9BOAO; Tue, 18 Feb 2020 17:21:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id EFCCC1600B2; Tue, 18 Feb 2020 17:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 9klYlsm7R4KW; Tue, 18 Feb 2020 17:21:58 -0800 (PST) Received: from Penguin.CS.UCLA.EDU (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D2E5C1600AF; Tue, 18 Feb 2020 17:21:58 -0800 (PST) Subject: Re: bug#39529: 28.0.50; Metahelp does not contain help text To: Pip Cet References: <875zgf8trz.fsf@gmail.com> <83d0and0q9.fsf@gnu.org> <83blq7d06n.fsf@gnu.org> <59be714f-1b52-a068-70c8-3204cf016ca2@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Tue, 18 Feb 2020 17:21:58 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 39529 Cc: 39529@debbugs.gnu.org, Eli Zaretskii , federicotedin@gmail.com 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 (---) On 2/18/20 11:56 AM, Pip Cet wrote: > if we rely on the precise > definitions of XHASH etc. that were in place prior to the January > changes, no "quick fix" was needed; it was simply the case that the > predicate used by hash tables created with :test equal diverged from > the built-in `equal' predicate in one more way than was already > documented. (Those documented deviations are that mutations of hash > keys won't cause rehashing, and that equal will sometimes signal for > (equal a b) but not for (equal b a)). I'm not aware of these deviations - where are they documented? What I see in the Emacs 27 documentation, under "Defining Hash Comparisons", is the statement that the hash and equality functions' "behavior should depend on only on properties of the keys that do not change". This is true of 'equal' and 'sxhash-equal' if one does not mutate any key that's in the hash table. So from what I can see, the predicates are supposed to be the same, it's just that one can't mutate keys. Also, I don't understand what is meant by "the predicate used by hash tables created with :test equal diverged from the built-in `equal' predicate". cmpfn_equal simply calls Fequal, so how can their behaviors diverge? >>> The pure-cons hash, and many other places, assume "equal" means >>> "equivalent" in some way. That's not true for bytecode objects, where >>> a function always returning `nil' can be equal to one always returning >>> `t'. >> >> Could you give an example of this? When I byte-compiled this: > > (defun f () (let ((x '(#1=(nil) . #1#))) > (eq (car x) (cdr x)))) > (defun g () (let ((x '((nil) . (nil))) > (eq (car x) (cdr x)))) > > That's somewhat contrived; more realistic examples where this might > actually be a problem would use string properties. Although this example is a good one that illustrates a bug (or at least a poorly-documented feature) in dumping, it hasn't changed because of the January 7 changes to sxhash. The same issue exists in Emacs 27 (and in Emacs 26 for that matter). So I'd rather address this issue separately, perhaps simply by documenting it for now. > I'll propose one more thing, which sounds horrible at first but might > be the least horrible option: accept that `equal', the function, and > `:test equal', the hash table predicate, have diverged significantly > already. Again I'm not following, because the two functions haven't diverged as far as I can see. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 18 21:35:23 2020 Received: (at 39529) by debbugs.gnu.org; 19 Feb 2020 02:35:23 +0000 Received: from localhost ([127.0.0.1]:41505 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4FCt-0004DT-7F for submit@debbugs.gnu.org; Tue, 18 Feb 2020 21:35:23 -0500 Received: from mail-ot1-f47.google.com ([209.85.210.47]:39092) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4FCs-0004DD-7O for 39529@debbugs.gnu.org; Tue, 18 Feb 2020 21:35:22 -0500 Received: by mail-ot1-f47.google.com with SMTP id 77so21669056oty.6 for <39529@debbugs.gnu.org>; Tue, 18 Feb 2020 18:35:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=csse3FOL92fpzWbNyySsnIEOK8hLbvGLH4t6vZldsJg=; b=fO1uwBZhK4QmW6v6g9fMZeOQzJ7G8CmiUP4FHsR0VAHHBHKB0XQqj/Kp5db7341Bzq MJlj7utqhAJzSHzAsj1mvlFBZSdC7ZPyxXaGk6p+7HR6Abef1zlBvBlbxKe5tqaG3HIZ pR8mO0zbnMFwd9okkqmBcOtze+LfJoF9Pq9qfzdqubbJYNPpNkpDjXNMbDAaM/CWoG8f /J5QcIardqTJ4x/221XOGChTKMXuLhnLrsM6gX6FSWdGoKVDGgZ+HYn8QzO/DaJVHpk1 o32Sks8GNHokAAK+TwxXkevoCNc1Pn6nl0wIv6CxMNd+tM5B/fCrKLhCnXK+VcUf5Wra W0pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=csse3FOL92fpzWbNyySsnIEOK8hLbvGLH4t6vZldsJg=; b=gr1EVLpDZL8t8s9UZ55Qnb2wtioB/NHH+Rdv8N25dgL+iseHOSPAK9qwKwGbz77oWQ ncJ8WgaL8dXDTvb4hgeCloP8q4qVrlaf+UMNqrngUJNOND8PxtHuG8NvCIs/aqTDesZa 6d3hLqFDIWzzwwcucASMzbP/W8+4sBAZzkoTxFh36HADtgs/CpnjSXpuY1q6d4IXKWvM XRzWrG4QNbDq6meJ/HGm7rU3qoGK2UKQrdiEQpxEIszMy0bN0rYtDKFJhiW24RyCJgWK Ijr+YIufzbd+b9EmPer1WID2z1+KtbKBKOTASCZaWmEGEWJ8yD/kWiHrTrkZtjOJ4dzH 2CDg== X-Gm-Message-State: APjAAAVy9L0p38ewk56zkg0s4jDJEgC8uwWgNjKcEDFU08lF8BTE0ARP hWgECQeM3NG4STNP/KRzanUd5OEWK/0W2IQqG9k= X-Google-Smtp-Source: APXvYqyV18/9cZ5+JbGPFLSbLEsaqI3d5VXlaMqep547ia/uJbgyVsgYvwc1BMJ89AUerDF8BsK1/P9XzoBmexlFvps= X-Received: by 2002:a9d:7511:: with SMTP id r17mr16753321otk.154.1582079716354; Tue, 18 Feb 2020 18:35:16 -0800 (PST) MIME-Version: 1.0 References: <875zgf8trz.fsf@gmail.com> <83d0and0q9.fsf@gnu.org> <83blq7d06n.fsf@gnu.org> <59be714f-1b52-a068-70c8-3204cf016ca2@cs.ucla.edu> In-Reply-To: From: Pip Cet Date: Wed, 19 Feb 2020 02:34:39 +0000 Message-ID: Subject: Re: bug#39529: 28.0.50; Metahelp does not contain help text To: Paul Eggert Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 39529 Cc: 39529@debbugs.gnu.org, Eli Zaretskii , federicotedin@gmail.com 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 (-) On Wed, Feb 19, 2020 at 1:22 AM Paul Eggert wrote: > > On 2/18/20 11:56 AM, Pip Cet wrote: > > > if we rely on the precise > > definitions of XHASH etc. that were in place prior to the January > > changes, no "quick fix" was needed; it was simply the case that the > > predicate used by hash tables created with :test equal diverged from > > the built-in `equal' predicate in one more way than was already > > documented. (Those documented deviations are that mutations of hash > > keys won't cause rehashing, and that equal will sometimes signal for > > (equal a b) but not for (equal b a)). > > I'm not aware of these deviations - where are they documented? > > What I see in the Emacs 27 documentation, under "Defining Hash > Comparisons", is the statement that the hash and equality functions' > "behavior should depend on only on properties of the keys that do not > change". That sentence is what I was referring to by "mutations of hash keys won't cause rehashing", which is one of the deviations. The other one is documented in objects.texi: Comparing circular lists may therefore cause deep recursion that leads to an error, and this may result in counterintuitive behavior such as @code{(equal a b)} returning @code{t} whereas @code{(equal b a)} signals an error. > This is true of 'equal' and 'sxhash-equal' if one does not > mutate any key that's in the hash table. So from what I can see, the > predicates are supposed to be the same, it's just that one can't mutate > keys. > > Also, I don't understand what is meant by "the predicate used by hash > tables created with :test equal diverged from the built-in `equal' > predicate". cmpfn_equal simply calls Fequal, so how can their behaviors > diverge? cmpfn_equal is only called when the numeric hashes are equal, so the actual predicate used is sxhash_equal (a) == sxhash_equal (b) && Fequal (a, b). That diverged from Fequal (a, b) in the case where a and b are markers, for example. > > >>> The pure-cons hash, and many other places, assume "equal" means > >>> "equivalent" in some way. That's not true for bytecode objects, where > >>> a function always returning `nil' can be equal to one always returning > >>> `t'. > >> > >> Could you give an example of this? When I byte-compiled this: > > > > (defun f () (let ((x '(#1=(nil) . #1#))) > > (eq (car x) (cdr x)))) > > (defun g () (let ((x '((nil) . (nil))) > > (eq (car x) (cdr x)))) > > > > That's somewhat contrived; more realistic examples where this might > > actually be a problem would use string properties. > > Although this example is a good one that illustrates a bug (or at least > a poorly-documented feature) in dumping, it hasn't changed because of > the January 7 changes to sxhash. True. My point was that "equal" is a problematic hash predicate, at least currently. > The same issue exists in Emacs 27 (and > in Emacs 26 for that matter). So I'd rather address this issue > separately, perhaps simply by documenting it for now. Agreed. > > I'll propose one more thing, which sounds horrible at first but might > > be the least horrible option: accept that `equal', the function, and > > `:test equal', the hash table predicate, have diverged significantly > > already. > Again I'm not following, because the two functions haven't diverged as > far as I can see. (defun hash-equal (a b) (let ((ht (make-hash-table :test 'equal))) (puthash a t ht) (gethash b ht))) (hash-equal (point-marker) (point-marker)) (equal (point-marker) (point-marker)) From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 19 04:00:47 2020 Received: (at 39529) by debbugs.gnu.org; 19 Feb 2020 09:00:47 +0000 Received: from localhost ([127.0.0.1]:41634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4LDr-0005Lr-2v for submit@debbugs.gnu.org; Wed, 19 Feb 2020 04:00:47 -0500 Received: from zimbra.cs.ucla.edu ([131.179.128.68]:48516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1j4LDo-0005Lc-3R for 39529@debbugs.gnu.org; Wed, 19 Feb 2020 04:00:45 -0500 Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 5C456160087; Wed, 19 Feb 2020 01:00:38 -0800 (PST) Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id RzfMcDnzIAp9; Wed, 19 Feb 2020 01:00:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id A67F41600AF; Wed, 19 Feb 2020 01:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id HY7R6nyGF-q1; Wed, 19 Feb 2020 01:00:37 -0800 (PST) Received: from [192.168.1.9] (cpe-23-242-74-103.socal.res.rr.com [23.242.74.103]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 71D31160087; Wed, 19 Feb 2020 01:00:37 -0800 (PST) Subject: Re: bug#39529: 28.0.50; Metahelp does not contain help text To: Pip Cet References: <875zgf8trz.fsf@gmail.com> <83d0and0q9.fsf@gnu.org> <83blq7d06n.fsf@gnu.org> <59be714f-1b52-a068-70c8-3204cf016ca2@cs.ucla.edu> From: Paul Eggert Organization: UCLA Computer Science Department Message-ID: Date: Wed, 19 Feb 2020 01:00:37 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 39529 Cc: 39529@debbugs.gnu.org, Eli Zaretskii , federicotedin@gmail.com 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 (---) On 2/18/20 6:34 PM, Pip Cet wrote: > (defun hash-equal (a b) > (let ((ht (make-hash-table :test 'equal))) > (puthash a t ht) > (gethash b ht))) > > (hash-equal (point-marker) (point-marker)) > (equal (point-marker) (point-marker)) Ah, OK, then I think we're in fundamental agreement about the problem. However, I don't agree that the Emacs 27-and-earlier approach is tenable, as means that (and (equal a b) (gethash a ht) (not (gethash b ht))) can return t, and similarly unexpected and undesirable behavior elsewhere - even if there are no side effects on hash keys and no cycles in hash key values. For now it should suffice if Emacs handles the case where hash keys don't change and don't have cycles; we can worry about the fancier problems later (if ever). From unknown Sun Jun 15 08:37:20 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 18 Mar 2020 11:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator