Subject: bug#39529: closed (Re: bug#39529: 28.0.50; Metahelp does not contain help text)

From: [email-masked] (GNU bug Tracking System)
Date: Sat, 15 Feb 2020 23:26:02 +0000

Your bug report

#39529: 28.0.50; Metahelp does not contain help text

which was filed against the emacs package, has been closed.

The explanation is attached below, along with your original report.
If you require more details, please reply to [email-masked].

-- 
39529: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=39529
GNU Bug Tracking System
Contact [email-masked] with problems

Subject: Re: bug#39529: 28.0.50; Metahelp does not contain help text
From: Paul Eggert <[email-masked]>
To: Eli Zaretskii <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Sat, 15 Feb 2020 15:25:44 -0800
List-Id: <debbugs-submit.debbugs.gnu.org>

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.
>From 3480071dfab30eaca7f1d014600b864d2ea22f62 Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email-masked]>
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=UTF-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:[email-masked].
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’t 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 first_in_list)
 	  vec = XVECTOR (tmp);
 	  if (vec->header.size == 0)
 	    invalid_syntax ("Empty byte-code object");
+
+	  if (COMPILED_DOC_STRING < vec->header.size
+	      && AREF (tmp, COMPILED_DOC_STRING) == 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 = XHASH (tmp) | (INTMASK - INTMASK / 2);
+	      ASET (tmp, COMPILED_DOC_STRING, make_ufixnum (hash));
+	    }
+
 	  make_byte_code (vec);
 	  return tmp;
 	}
-- 
2.17.1

Subject: 28.0.50; Metahelp does not contain help text
From: Federico Tedin <[email-masked]>
To: [email-masked]
Date: Sun, 09 Feb 2020 20:06:40 +0100
List-Id: <debbugs-submit.debbugs.gnu.org>

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).