Subject: bug#41680: closed (Re: Recent compiled byte code changes broke loading)

From: [email-masked] (GNU bug Tracking System)
Date: Wed, 03 Jun 2020 01:44:02 +0000

Your bug report

#41680: Recent compiled byte code changes broke loading

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

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

Subject: Re: Recent compiled byte code changes broke loading
From: Paul Eggert <[email-masked]>
To: Daniel Colascione <[email-masked]>
Cc: [email-masked]
Date: Tue, 2 Jun 2020 18:43:50 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

Thanks for reporting that bug. I installed the attached patch, which should fix
it, and am boldly closing the bug report.
>From 00613f4c4a464c16d6d50a34e1b8b68fc50f2d2e Mon Sep 17 00:00:00 2001
From: Paul Eggert <[email-masked]>
Date: Tue, 2 Jun 2020 18:40:10 -0700
Subject: [PATCH] Fix bug in recent byte-code checking hoist

Problem reported by Daniel Colascione (Bug#41680).
* src/lread.c (read1): Check that AREF (tmp, COMPILED_BYTECODE)
is a string before subjecting it to STRING_MULTIBYTE.
Be more consistent about using AREF in the neighborhood,
to help prevent this sort of problem from recurring.
---
 src/lread.c | 21 +++++++++++----------
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/src/lread.c b/src/lread.c
index 29deddaf15..8064bf4d0e 100644
--- a/src/lread.c
+++ b/src/lread.c
@@ -2966,17 +2966,18 @@ read1 (Lisp_Object readcharfun, int *pch, bool first_in_list)
 	  struct Lisp_Vector *vec;
 	  tmp = read_vector (readcharfun, 1);
 	  vec = XVECTOR (tmp);
-	  if (! (COMPILED_STACK_DEPTH < vec->header.size
-		 && (FIXNUMP (vec->contents[COMPILED_ARGLIST])
-		     || CONSP (vec->contents[COMPILED_ARGLIST])
-		     || NILP (vec->contents[COMPILED_ARGLIST]))
-		 && ((STRINGP (vec->contents[COMPILED_BYTECODE])
-		      && VECTORP (vec->contents[COMPILED_CONSTANTS]))
-		     || CONSP (vec->contents[COMPILED_BYTECODE]))
-		 && FIXNATP (vec->contents[COMPILED_STACK_DEPTH])))
+	  if (! (COMPILED_STACK_DEPTH < ASIZE (tmp)
+		 && (FIXNUMP (AREF (tmp, COMPILED_ARGLIST))
+		     || CONSP (AREF (tmp, COMPILED_ARGLIST))
+		     || NILP (AREF (tmp, COMPILED_ARGLIST)))
+		 && ((STRINGP (AREF (tmp, COMPILED_BYTECODE))
+		      && VECTORP (AREF (tmp, COMPILED_CONSTANTS)))
+		     || CONSP (AREF (tmp, COMPILED_BYTECODE)))
+		 && FIXNATP (AREF (tmp, COMPILED_STACK_DEPTH))))
 	    invalid_syntax ("Invalid byte-code object");
 
-	  if (STRING_MULTIBYTE (AREF (tmp, COMPILED_BYTECODE)))
+	  if (STRINGP (AREF (tmp, COMPILED_BYTECODE))
+	      && STRING_MULTIBYTE (AREF (tmp, COMPILED_BYTECODE)))
 	    {
 	      /* BYTESTR must have been produced by Emacs 20.2 or earlier
 		 because it produced a raw 8-bit string for byte-code and
@@ -2987,7 +2988,7 @@ read1 (Lisp_Object readcharfun, int *pch, bool first_in_list)
 		    Fstring_as_unibyte (AREF (tmp, COMPILED_BYTECODE)));
 	    }
 
-	  if (COMPILED_DOC_STRING < vec->header.size
+	  if (COMPILED_DOC_STRING < ASIZE (tmp)
 	      && EQ (AREF (tmp, COMPILED_DOC_STRING), make_fixnum (0)))
 	    {
 	      /* read_list found a docstring like '(#$ . 5521)' and treated it
-- 
2.17.1

Subject: Recent compiled byte code changes broke loading
From: "Daniel Colascione" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Tue, 2 Jun 2020 17:26:13 -0700
List-Id: <debbugs-submit.debbugs.gnu.org>

f0b0105d913a94c66f230874c9269b19dbbc83bd changes how we generate and
evaluate byte-code objects. It causes a weird wrong-type-argument when
loading some elc files, however:

Debugger entered--Lisp error: (wrong-type-argument stringp
("/home/dancol/emacs/conf/gnus.elc" . 1556))
  read(get-file-char)
  load("~/emacs/conf/gnus" nil t)
  (lambda nil (load "~/emacs/conf/gnus" nil t))()
  eval-after-load-helper("/home/dancol/edev/debug/lisp/gnus/gnus.elc")
  run-hook-with-args(eval-after-load-helper
"/home/dancol/edev/debug/lisp/gnus/gnus.elc")
  do-after-load-evaluation("/home/dancol/edev/debug/lisp/gnus/gnus.elc")

I did a bit of debugging. We're passing some kind of cons cell to the
Fstring_as_unibyte call in read1. (The CDR seems invalid too somehow?)

There's a difference in the generated elc file ("gnus.elc" above) that
seems to drive the error.

Bad: (defalias 'qtmstr-setup-summary-mode #[nil #@38 ("\300\301!\207" .
[hl-line-mode 1])(#$ . 1556) nil 2])

Good: (defalias 'qtmstr-setup-summary-mode #[nil "\300\301!\207"
[hl-line-mode 1] 2])

Reverting f0b0105d913a94c66f230874c9269b19dbbc83bd seems to fix the
problem for now.