unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Error "load: Symbol’s value as variable is void: \213" since 261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137
@ 2022-08-06  2:05 Campbell Barton
  2022-08-06  9:16 ` Stefan Kangas
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: Campbell Barton @ 2022-08-06  2:05 UTC (permalink / raw)
  To: Emacs developers

Hi ever since 261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137 I'm getting an
error starting emacs,
to be sure there isn't anything strange going on, this happens with a
clean build, ELN removed (with/without native compilation), and with a
freshly installed package directory.

--- error output ---
Debugger entered--Lisp error: (void-variable ‹)
  eval-buffer(#<buffer  *load*-527550> nil
"/opt/emacs/share/emacs/29.0.50/lisp/calc/calc-loaddefs.el.gz" nil t)
; Reading at buffer position 3
  load-with-code-conversion("/opt/emacs/share/emacs/29.0.50/lisp/calc/calc-load..."
"/opt/emacs/share/emacs/29.0.50/lisp/calc/calc-loaddefs.el.gz" nil t)
  load("calc-loaddefs.el" nil t)
  require(calc)
--- snip ---

This error happens to be triggered by evil-mode but if I disable evil
mode it gets triggered by lsp-mode, so it doesn't seem specific to a
single package,
although `emacs -Q` works without problems.

I bisected the error to:
http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137

Is this a known problem or is it worth a fill bug report?

-- 
- Campbell



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Error "load: Symbol’s value as variable is void: \213" since 261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137
  2022-08-06  2:05 Error "load: Symbol’s value as variable is void: \213" since 261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137 Campbell Barton
@ 2022-08-06  9:16 ` Stefan Kangas
  2022-08-06 12:22 ` Lars Ingebrigtsen
  2022-08-06 15:50 ` Zhiwei Chen
  2 siblings, 0 replies; 5+ messages in thread
From: Stefan Kangas @ 2022-08-06  9:16 UTC (permalink / raw)
  To: Campbell Barton, Emacs developers

Campbell Barton <ideasman42@gmail.com> writes:

> Is this a known problem or is it worth a fill bug report?

In general, it is better to just file a bug report than asking this
question.  If it is a known issue, we will merge your new report with
an old one.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Error "load: Symbol’s value as variable is void: \213" since 261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137
  2022-08-06  2:05 Error "load: Symbol’s value as variable is void: \213" since 261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137 Campbell Barton
  2022-08-06  9:16 ` Stefan Kangas
@ 2022-08-06 12:22 ` Lars Ingebrigtsen
  2022-08-06 15:50 ` Zhiwei Chen
  2 siblings, 0 replies; 5+ messages in thread
From: Lars Ingebrigtsen @ 2022-08-06 12:22 UTC (permalink / raw)
  To: Campbell Barton; +Cc: Emacs developers

Campbell Barton <ideasman42@gmail.com> writes:

>   load("calc-loaddefs.el" nil t)
>   require(calc)
> --- snip ---
>
> This error happens to be triggered by evil-mode but if I disable evil
> mode it gets triggered by lsp-mode, so it doesn't seem specific to a
> single package,
> although `emacs -Q` works without problems.

If you say

emacs -Q
M-: (require 'calc)

does that trigger the problem for you?



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Error "load: Symbol’s value as variable is void: \213" since 261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137
  2022-08-06  2:05 Error "load: Symbol’s value as variable is void: \213" since 261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137 Campbell Barton
  2022-08-06  9:16 ` Stefan Kangas
  2022-08-06 12:22 ` Lars Ingebrigtsen
@ 2022-08-06 15:50 ` Zhiwei Chen
  2022-08-07  4:19   ` Campbell Barton
  2 siblings, 1 reply; 5+ messages in thread
From: Zhiwei Chen @ 2022-08-06 15:50 UTC (permalink / raw)
  To: Campbell Barton; +Cc: Emacs developers

Campbell Barton <ideasman42@gmail.com> writes:

> Hi ever since 261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137 I'm getting an
> error starting emacs,
> to be sure there isn't anything strange going on, this happens with a
> clean build, ELN removed (with/without native compilation), and with a
> freshly installed package directory.
>
> --- error output ---
> Debugger entered--Lisp error: (void-variable ‹)
>   eval-buffer(#<buffer  *load*-527550> nil
> "/opt/emacs/share/emacs/29.0.50/lisp/calc/calc-loaddefs.el.gz" nil t)
> ; Reading at buffer position 3
>   load-with-code-conversion("/opt/emacs/share/emacs/29.0.50/lisp/calc/calc-load..."
> "/opt/emacs/share/emacs/29.0.50/lisp/calc/calc-loaddefs.el.gz" nil t)
>   load("calc-loaddefs.el" nil t)
>   require(calc)
> --- snip ---
>
> This error happens to be triggered by evil-mode but if I disable evil
> mode it gets triggered by lsp-mode, so it doesn't seem specific to a
> single package,
> although `emacs -Q` works without problems.
>
> I bisected the error to:
> http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137
>
> Is this a known problem or is it worth a fill bug report?

I suspect you're the victim of `file-name-handler-alist' optimization
[1]. Since it sets `file-name-handler-alist' to nil, it can't unpack
*.el.gz on-the-fly and then eval it.

    $ hexdump /usr/share/emacs/29.0.50/lisp/files.el.gz -C | head -n1
    00000000  1f 8b 08 00 00 00 00 00  02 03 ec 5c ff 73 db 46  |...........\.s.F|

The '\213' (0x8b) is the second byte of an el.gz file.

[1]: https://github.com/doomemacs/doomemacs/blob/master/early-init.el#L31-L48

-- 
Zhiwei Chen



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Error "load: Symbol’s value as variable is void: \213" since 261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137
  2022-08-06 15:50 ` Zhiwei Chen
@ 2022-08-07  4:19   ` Campbell Barton
  0 siblings, 0 replies; 5+ messages in thread
From: Campbell Barton @ 2022-08-07  4:19 UTC (permalink / raw)
  To: Zhiwei Chen; +Cc: Emacs developers

On Sun, Aug 7, 2022 at 1:50 AM Zhiwei Chen <condy0919@gmail.com> wrote:
>
> Campbell Barton <ideasman42@gmail.com> writes:
>
> > Hi ever since 261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137 I'm getting an
> > error starting emacs,
> > to be sure there isn't anything strange going on, this happens with a
> > clean build, ELN removed (with/without native compilation), and with a
> > freshly installed package directory.
> >
> > --- error output ---
> > Debugger entered--Lisp error: (void-variable ‹)
> >   eval-buffer(#<buffer  *load*-527550> nil
> > "/opt/emacs/share/emacs/29.0.50/lisp/calc/calc-loaddefs.el.gz" nil t)
> > ; Reading at buffer position 3
> >   load-with-code-conversion("/opt/emacs/share/emacs/29.0.50/lisp/calc/calc-load..."
> > "/opt/emacs/share/emacs/29.0.50/lisp/calc/calc-loaddefs.el.gz" nil t)
> >   load("calc-loaddefs.el" nil t)
> >   require(calc)
> > --- snip ---
> >
> > This error happens to be triggered by evil-mode but if I disable evil
> > mode it gets triggered by lsp-mode, so it doesn't seem specific to a
> > single package,
> > although `emacs -Q` works without problems.
> >
> > I bisected the error to:
> > http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137
> >
> > Is this a known problem or is it worth a fill bug report?
>
> I suspect you're the victim of `file-name-handler-alist' optimization
> [1]. Since it sets `file-name-handler-alist' to nil, it can't unpack
> *.el.gz on-the-fly and then eval it.
>
>     $ hexdump /usr/share/emacs/29.0.50/lisp/files.el.gz -C | head -n1
>     00000000  1f 8b 08 00 00 00 00 00  02 03 ec 5c ff 73 db 46  |...........\.s.F|
>
> The '\213' (0x8b) is the second byte of an el.gz file.
>
> [1]: https://github.com/doomemacs/doomemacs/blob/master/early-init.el#L31-L48
>
> --
> Zhiwei Chen

This was the problem, thanks!

Aside from avoiding setting `file-name-handler-alist` to nil entirely,
The error can be avoided by removing  `--without-compress-install`
when building emacs.

An alternative could also be to limit the alist to only use
compression handlers, e.g:
(setq file-name-handler-alist (list (rassoc 'jka-compr-handler
my-original-file-name-handler-alist)))
Although in my tests this loses the performance gains from setting it to nil.

Since this is a fairly common optimization it seems likely others may
run into it, so it may be good if the error message could be made less
cryptic somehow, although I'm not sure if that's reasonable.
-- 
- Campbell



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2022-08-07  4:19 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-08-06  2:05 Error "load: Symbol’s value as variable is void: \213" since 261d6afd6e6f3ba2bbf4db0d9ac57b0cbacc0137 Campbell Barton
2022-08-06  9:16 ` Stefan Kangas
2022-08-06 12:22 ` Lars Ingebrigtsen
2022-08-06 15:50 ` Zhiwei Chen
2022-08-07  4:19   ` Campbell Barton

Code repositories for project(s) associated with this 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).