GNU bug report logs - #54079
29.0.50; Method dispatching eratically fails

Previous Next

Package: emacs;

Reported by: Michael Heerdegen <michael_heerdegen <at> web.de>

Date: Mon, 21 Feb 2022 00:14:02 UTC

Severity: normal

Found in version 29.0.50

Done: Alan Mackenzie <acm <at> muc.de>

Bug is archived. No further changes may be made.

Full log


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

From: Alan Mackenzie <acm <at> muc.de>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: John Wiegley <jwiegley <at> gmail.com>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 acm <at> muc.de, 54079 <at> debbugs.gnu.org,
 Thierry Volpiatto <thierry.volpiatto <at> gmail.com>
Subject: Re: bug#54079: 29.0.50; Method dispatching eratically fails
Date: Wed, 16 Mar 2022 11:52:29 +0000
On Wed, Mar 16, 2022 at 02:44:07 +0100, Michael Heerdegen wrote:
> Alan Mackenzie <acm <at> muc.de> writes:

> > OK.  So the longer I hear nothing from you, the better.  ;-)  Thanks!

> Hope it was long enough :-)

Indeed it was!  Thanks!

As you'll have gathered, I've been debating the final form of the patch
with Stefan M. for the last week.  The patch I'll actually be committing
will be slightly different from the one from last week, but not in any
way which should affect the success of the problem fix.

> I now tried to debug the other thing that is still happening for me -
> failing compilation with async-bytecomp.el when updating packages with
> M-x list-packages (I CC the maintainers).

> In my currently running session I get

> #+begin_src emacs-lisp
> (async-inject-variables "\\`\\(?:load-path\\'\\|byte-\\)")
>   ==>
>   (setq byte-set-marker 147 byte-optimize--dynamic-vars
>         '(#<symbol magit-log-margin at 854429>
>           #<symbol magit-status-mode-map at 854375> ...)
>         ...)
> #+end_src

> These symbols with position in that sexp seem to be the, or one, cause
> of the trouble.  The symbols directly come from a `mapatoms' call, and
> AFAIK this sexp is then `print'ed and sent to another emacs process,
> where it causes a `read' error.

> What has to be done to fix this one?

I don't know, as yet.  Almost certainly, the symbols with position are
somehow escaping from the compilation context.  It looks like something
in magit.  Possibly, I'll need to ask the magit maintainer to call
byte-run-strip-symbol-positions (which _surely_ ought to be renamed to
strip_symbol_positions) where these SWPs escape.  (Possibly in a macro).

In the meantime, could you possibly raise a fresh bug report for this
one, please, and give a complete recipe for reproducing the bug.
Thanks!

> TIA,

> Michael.




This bug report was last modified 3 years and 67 days ago.

Previous Next


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