GNU bug report logs - #66022
30.0.50; kmacro overwriting global keybindings

Previous Next

Package: emacs;

Reported by: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Date: Sat, 16 Sep 2023 06:39:02 UTC

Severity: normal

Found in version 30.0.50

Fixed in version 30.1

Done: Gerd Möllmann <gerd.moellmann <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


Message #113 received at 66022 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 66022 <at> debbugs.gnu.org
Subject: Re: bug#66022: 30.0.50; kmacro overwriting global keybindings
Date: Mon, 18 Sep 2023 13:00:09 -0400
> Sorry, missed copying a line from the terminal
>
> / >  ls -l /Applications/Emacs.app/Contents/Resources/lisp/loaddefs.el* 
> -rw-r--r--  1 gerd  admin   377687 Sep 17 16:36
> /Applications/Emacs.app/Contents/Resources/lisp/loaddefs.el.gz
> -rw-r--r--  1 gerd  admin  1467107 Sep 17 16:38
> /Applications/Emacs.app/Contents/Resources/lisp/loaddefs.elc
>  gerd <at> Pro 2023-09-18 18:32 
> ~/ > 

I believe the `lread.c` code which calls `Fload` should be looking at
the `loaddefs.elc` file here, so removing the `.el.gz` should make
no difference.

Now why does it feel the need to reload this file?  The way the code
works is that it receives a (FILE . POS) pair where FILE should
presumably point to the `loaddefs.elc`.

When it opens that `.elc` file, POS should point to the beginning of the
desired docstring with nearby info indicating the length of
that docstring.

If the file was changed in the mean time, POS may end up
pointing elsewhere.  `lread.c` performs a sanity check to make sure POS
points to something that does indeed look like a docstring and
apparently in your case that sanity check fails.

My crystal ball suggests maybe you're witnessing a bug in the build
process where we end up *re*compiling `loaddefs.elc` a second time
(maybe because we regenerate/refresh `loaddefs.el` by error) after
Emacs was dumped, maybe during the "install" step that builds the
`Emacs.app`.

Normally, the way things are supposed to work is:

- build temacs.
- dump bootstrap-emacs using some old `loaddefs.el(c)` of
  `ldefs-boot.el`.
- compile the preloaded files and build the true `loaddefs.el`.
- dump the final `emacs` executable.
- keep compiling the rest.

But if "keep compiling the rest" ends up touching a dependency of
`loaddefs.el` subsequent steps like `install` could decide to make poor
decisions :-(

IOW rebuild, keeping a log and check what was done in which order.


        Stefan





This bug report was last modified 1 year and 228 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.