[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#53164: (After an ELC+ELN build, don't load the source file into a bu
From: |
Alan Mackenzie |
Subject: |
bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed. |
Date: |
Mon, 10 Jan 2022 20:21:40 +0000 |
Hello, Eli.
On Mon, Jan 10, 2022 at 21:53:36 +0200, Eli Zaretskii wrote:
> > Date: Mon, 10 Jan 2022 19:34:58 +0000
> > Cc: 53164@debbugs.gnu.org
> > From: Alan Mackenzie <acm@muc.de>
> > > 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.
> After reading this, I still don't understand how come you bump into
> this problem, whereas I don't, and neither does anyone else who builds
> the release branch with native-compilation. Is this something
> specific to that branch you are working on?
Indeed, yes. It is the symbols with position which escaped from a
compiler macro.
> If so, why is it urgent to have the fix on the release branch? The
> branch on which you ware working will land on master.
There was no urgency. I though the convention was for documentation
fixes and simple safe code fixes to go onto the release branch. The fix
to this bug, a single line, is well understood and certainly comes into
the category of simple and safe.
> > 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.
> There's always one more bug. When we are so far into the pretest
> process, problems that take unusual steps to reproduce are not
> important enough to delay the release.
OK. But can I ask you to consider announcing on emacs-devel when the
criteria for making bug fixes on the release branch change? Apologies if
you have done, and I missed it.
> The judgment call I need to make is how important is it to have this in
> the release branch, and that's only after I understand how to trigger
> the problem in the first place.
It is not particularly important for the release branch. But it is a
positive step (making the build faster, and removing a potential bug
source).
As for triggering it, I cannot give you a recipe except for committing my
recent changes to scratch/correct-warning-pos, and asking you to repeat
what I did (basically, a make bootstrap). Somebody else may trigger it
in some other way, and the debugging effort is potentially unbounded.
So, I still think it would be better in the release branch, but can see
that it's not very important.
There're three ways we could go. Commit it in emacs-28, master, or
scratch/correct-warning-pos. I'm willing to commit it again in any of
these places.
> Thanks.
--
Alan Mackenzie (Nuremberg, Germany).
- bug#53164: After an ELC+ELN build, don't load the source file into a buffer., Alan Mackenzie, 2022/01/10
- bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed., Alan Mackenzie, 2022/01/10
- bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed., Eli Zaretskii, 2022/01/10
- bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed., Alan Mackenzie, 2022/01/10
- bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed., Eli Zaretskii, 2022/01/10
- bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed.,
Alan Mackenzie <=
- bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed., Eli Zaretskii, 2022/01/11
- bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed., Alan Mackenzie, 2022/01/11
- bug#53164: (After an ELC+ELN build, don't load the source file into a buffer.) fixed., Eli Zaretskii, 2022/01/11
bug#53164: After an ELC+ELN build, don't load the source file into a buffer., Eli Zaretskii, 2022/01/10