From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.bugs Subject: bug#39529: 28.0.50; Metahelp does not contain help text Date: Sat, 15 Feb 2020 15:25:44 -0800 Organization: UCLA Computer Science Department Message-ID: References: <875zgf8trz.fsf@gmail.com> <83d0and0q9.fsf@gnu.org> <83blq7d06n.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------BB186750EA64155729615E92" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="107697"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.4.1 Cc: 39529-done@debbugs.gnu.org, federicotedin@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Feb 16 00:26:26 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1j36pN-000RvS-TX for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Feb 2020 00:26:25 +0100 Original-Received: from localhost ([::1]:55564 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j36pM-0007zo-Eu for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 15 Feb 2020 18:26:24 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:32840) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j36p2-0007tl-KN for bug-gnu-emacs@gnu.org; Sat, 15 Feb 2020 18:26:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j36p0-0007X3-GF for bug-gnu-emacs@gnu.org; Sat, 15 Feb 2020 18:26:04 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:58846) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j36p0-0007WO-CN for bug-gnu-emacs@gnu.org; Sat, 15 Feb 2020 18:26:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j36p0-000405-9d for bug-gnu-emacs@gnu.org; Sat, 15 Feb 2020 18:26:02 -0500 Resent-From: Paul Eggert Original-Sender: "Debbugs-submit" Resent-To: bug-gnu-emacs@gnu.org Resent-Date: Sat, 15 Feb 2020 23:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: cc-closed 39529 X-GNU-PR-Package: emacs Mail-Followup-To: 39529@debbugs.gnu.org, eggert@cs.ucla.edu, federicotedin@gmail.com Original-Received: via spool by 39529-done@debbugs.gnu.org id=D39529.158180915715356 (code D ref 39529); Sat, 15 Feb 2020 23:26:02 +0000 Original-Received: (at 39529-done) by debbugs.gnu.org; 15 Feb 2020 23:25:57 +0000 Original-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 Original-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 Original-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) Original-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) Original-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 Original-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) Original-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) In-Reply-To: <83blq7d06n.fsf@gnu.org> Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:176099 Archived-At: 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--