unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 53164@debbugs.gnu.org
Subject: bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed.
Date: Mon, 10 Jan 2022 19:34:58 +0000	[thread overview]
Message-ID: <YdyKYsWkLvZTS556@ACM> (raw)
In-Reply-To: <83v8yr8o0t.fsf@gnu.org>

Hello, Eli.

On Mon, Jan 10, 2022 at 20:05:22 +0200, Eli Zaretskii wrote:
> > Date: Mon, 10 Jan 2022 17:15:34 +0000
> > From: Alan Mackenzie <acm@muc.de>

> > Bug fixed in the emacs-28 branch.

> I reverted that commit.  Please don't make any non-trivial changes on
> the release branch without asking first, and definitely not without
> explaining the problem and the solution in much more detail than you
> did.

It seemed to me like such an obvious fix for a non-obvious bug which can
cause serious amounts of time to be lost (see below), and with a
negligible chance of doing any damage.

But after reading the following, please consider putting it back.  It
will make building Emacs faster, even if only a little bit.

> FTR, I didn't see any build problems due to this issue, not even
> once.  So I wonder what exactly did you see and in what scenario.
> Please elaborate.

It took me practically three days solid to diagnose this bug.  The
symptom, whilst bootstrapping the scratch/correct-warning-pos, was the
following message on stderr:

    Error: (invalid-function #<symbol = at 18944>)

..  I quickly tracked down the source of the `=' symbol to lisp/subr.el,
in the code for `zerop'.  Further progress was elusive.  In the course
of debugging it, I ended up writing my own backtrace routine, free of
dependencies, which can work early in the bootstrap, unlike the standard
backtrace.

The course of events which led to that error message is this:

1. During the bootstrap with native compile, ELC+ELN compiles subr.el.
  It does so by getting the LAP code from bytecomp.el via a side
  channel.  It completes the compilation.
2. bootstrap-emacs now contains the native-compiled version of subr.el.
  Unfortunately, the macro `zerop--anon-cmacro' a complier macro for
  `zerop', still contains symbols with position.
3. Having finished the native compilation, ELC+ELN visited subr.el in a
  buffer, due to this bug.
4. As part of visiting subr.el, Emacs calls after-find-file, which
  invokes find-file-hook.
5. One of the entries in find-file-hook is vc-refresh-state, which gets
  called.
6. This causes vc-git.elc to be loaded.  Eventually, vc-git--out-ok gets
  called.
7. vc-git--out-ok invokes `zerop', or more precisely the code generated
  by the macro `zerop--anon-cmacro'.  This contains #<symbol = at
  18944>.
8. eval signals an error, since symbols-with-pos-enabled is nil and it
  thus can't handle the symbol with position.  This error gets blocked
  from reaching a backtrace function by an inconsiderate condition-case,
  which just dumps the message onto stderr.

The most obvious cause of the error seems to be at step 3, where
bootstrap-emacs spuriously visits the source file.

As I said above, please consider putting the fix to this bug back.  I do
not want anybody else to have to go through what I had to to track the
bug down.  Leaving stale arguments on the command line, later to be
visited, cannot possibly be the Right Thing.  I'm pretty sure it was not
done deliberately, it was just a minor oversight which didn't seem to
matter.

Thanks.

> Thanks.

-- 
Alan Mackenzie (Nuremberg, Germany).





  reply	other threads:[~2022-01-10 19:34 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-10 16:50 bug#53164: After an ELC+ELN build, don't load the source file into a buffer Alan Mackenzie
2022-01-10 17:15 ` bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed Alan Mackenzie
2022-01-10 18:05   ` Eli Zaretskii
2022-01-10 19:34     ` Alan Mackenzie [this message]
2022-01-10 19:53       ` Eli Zaretskii
2022-01-10 20:21         ` Alan Mackenzie
2022-01-11 12:27           ` Eli Zaretskii
2022-01-11 18:03             ` Alan Mackenzie
2022-01-11 18:45               ` Eli Zaretskii
2022-01-10 18:01 ` bug#53164: After an ELC+ELN build, don't load the source file into a buffer Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YdyKYsWkLvZTS556@ACM \
    --to=acm@muc.de \
    --cc=53164@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).