bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Dima Kogan]

Hi. I maintain Debian packages of bleeding-edge emacs builds:

  http://emacs.secretsauce.net/

Recently I enabled the native-comp flags for these packages. The results
mostly work, but a user sent me a bug report whose cause I just tracked
down. Some of this is probably my fault, as the packager, but there's an
emacs bug here too.

To tickle the bug the user needs to install the emacs-snapshot package,
but NOT the emacs-snapshot-el package. This results in the .elc files
being shipped, but NOT the .el files. This is a valid way to do it
without the native-comp patches, and the Debian emacs packages have
allowed this since forever.

If you install emacs like this, this happens:

  $ emacs-snapshot -Q -batch -f batch-native-compile empty.el

  Fatal error 11: Segmentation fault

The C backtrace is 6033 frames long, which can't be good. xbacktrace
says this:

  (gdb) xbacktrace
  "display-warning" (0xffebcfd8)
  "display-warning" (0xffebd5d8)
  .... lots more "display-warning"
  "locate-file" (0xffffe498)
  "command-line" (0xffffe5a0)
  "normal-top-level" (0xffffe640)

And the warning itself is:

  "Cannot look-up eln file as no source file was found for /usr/share/emacs/28.0.50/lisp/emacs-lisp/warnings.elc"

So something somewhere wanted to throw a warning, and this warning tried
to find its own sources, couldn't do it, and threw another warning. And
so on.

So first off, it'd be great if emacs could handle this without such a
recursive failure mode. It took me a long time to figure out what's
happening, and a plain-text error message on the console would have been
nice.

And second: how should this be packaged? Is shipping the .el files a
hard requirement now?

Thanks!

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Dima Kogan <dima@secretsauce.net> writes:

> Hi. I maintain Debian packages of bleeding-edge emacs builds:
>
>   http://emacs.secretsauce.net/
>
> Recently I enabled the native-comp flags for these packages. The results
> mostly work, but a user sent me a bug report whose cause I just tracked
> down. Some of this is probably my fault, as the packager, but there's an
> emacs bug here too.
>
> To tickle the bug the user needs to install the emacs-snapshot package,
> but NOT the emacs-snapshot-el package. This results in the .elc files
> being shipped, but NOT the .el files. This is a valid way to do it
> without the native-comp patches, and the Debian emacs packages have
> allowed this since forever.
>
> If you install emacs like this, this happens:
>
>   $ emacs-snapshot -Q -batch -f batch-native-compile empty.el
>
>   Fatal error 11: Segmentation fault
>
> The C backtrace is 6033 frames long, which can't be good. xbacktrace
> says this:
>
>   (gdb) xbacktrace
>   "display-warning" (0xffebcfd8)
>   "display-warning" (0xffebd5d8)
>   .... lots more "display-warning"
>   "locate-file" (0xffffe498)
>   "command-line" (0xffffe5a0)
>   "normal-top-level" (0xffffe640)
>
> And the warning itself is:
>
>   "Cannot look-up eln file as no source file was found for /usr/share/emacs/28.0.50/lisp/emacs-lisp/warnings.elc"
>
> So something somewhere wanted to throw a warning, and this warning tried
> to find its own sources, couldn't do it, and threw another warning. And
> so on.
>
> So first off, it'd be great if emacs could handle this without such a
> recursive failure mode. It took me a long time to figure out what's
> happening, and a plain-text error message on the console would have been
> nice.

Hi Dima,

could you share the Lisp backtrace?  If you have loaded the .gdbinit
shipped with the repot this will be at the bottom of the gdb backtrace.

> And second: how should this be packaged? Is shipping the .el files a
> hard requirement now?

Yes if you want the native compiler to be able to compile files,
otherwise you should either native compile all lisp files Ahead of Time
or set `comp-deferred-compilation' to nil in early init so that Emacs
will not try to native compile bytecode being loaded.

Thanks

  Andrea

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Dima Kogan]

Andrea Corallo <akrl@sdf.org> writes:

> could you share the Lisp backtrace? If you have loaded the .gdbinit
> shipped with the repot this will be at the bottom of the gdb
> backtrace.

Hi Andrea. The backtrace looks like this:

  "display-warning" (0xffebcfd8)
  "display-warning" (0xffebd5d8)
  "display-warning" (0xffebdbd8)
  "display-warning" (0xffebe1d8)
  "display-warning" (0xffebe7d8)
  "display-warning" (0xffebedd8)
  "display-warning" (0xffebf3d8)
  "display-warning" (0xffebf9d8)
  "display-warning" (0xffebffd8)
  "display-warning" (0xffec05d8)
  "display-warning" (0xffec0bd8)
  "display-warning" (0xffec11d8)
  "display-warning" (0xffec17d8)
  "display-warning" (0xffec1dd8)
  "display-warning" (0xffec23d8)
  "display-warning" (0xffec29d8)
  "display-warning" (0xffec2fd8)
  "display-warning" (0xffec35d8)
  "display-warning" (0xffec3bd8)
  "display-warning" (0xffec41d8)
  "display-warning" (0xffec47d8)
  "display-warning" (0xffec4dd8)
  "display-warning" (0xffec59d8)
  "display-warning" (0xffec5fd8)
  "display-warning" (0xffec65d8)
  "debug" (0xffec6bd8)
  "substitute-env-vars" (0xffec6e28)
  "substitute-env-in-file-name" (0xffec6ec8)
  "display-warning" (0xffec7248)
  ... 1000s more "display-warning"
  "locate-file" (0xffffe498)
  "command-line" (0xffffe5a0)
  "normal-top-level" (0xffffe640)

>> And second: how should this be packaged? Is shipping the .el files a
>> hard requirement now?

> Yes if you want the native compiler to be able to compile files,
> otherwise you should either native compile all lisp files Ahead of Time
> or set `comp-deferred-compilation' to nil in early init so that Emacs
> will not try to native compile bytecode being loaded.

That's helpful. Thanks.

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Date: Tue, 11 May 2021 01:44:03 -0700
> Cc: 48342@debbugs.gnu.org
> 
> Andrea Corallo <akrl@sdf.org> writes:
> 
> > could you share the Lisp backtrace? If you have loaded the .gdbinit
> > shipped with the repot this will be at the bottom of the gdb
> > backtrace.
> 
> Hi Andrea. The backtrace looks like this:
> 
>   "display-warning" (0xffebcfd8)
>   "display-warning" (0xffebd5d8)
>   "display-warning" (0xffebdbd8)
>   "display-warning" (0xffebe1d8)

Any idea how come display-warning calls itself?

> > Yes if you want the native compiler to be able to compile files,
> > otherwise you should either native compile all lisp files Ahead of Time
> > or set `comp-deferred-compilation' to nil in early init so that Emacs
> > will not try to native compile bytecode being loaded.
> 
> That's helpful. Thanks.

Note that if you will be distributing the *.eln files, I think the GPL
requires you to make the *.el files available.  In fact, this is so
even with the *.elc files.  So I'm not sure I understand how you could
distribute only the *.elc files until now: isn't that contrary to GPL?

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Gregory Heytings]

>>> Yes if you want the native compiler to be able to compile files, 
>>> otherwise you should either native compile all lisp files Ahead of 
>>> Time or set `comp-deferred-compilation' to nil in early init so that 
>>> Emacs will not try to native compile bytecode being loaded.
>>
>> That's helpful. Thanks.
>
> Note that if you will be distributing the *.eln files, I think the GPL 
> requires you to make the *.el files available.  In fact, this is so even 
> with the *.elc files.  So I'm not sure I understand how you could 
> distribute only the *.elc files until now: isn't that contrary to GPL?
>

Why would that be contrary to the GPL?  The *.el files are available on 
Debian and Debian-derived distrbutions, but Debian has chosen to make the 
distribution of Emacs more modular, and each "logical part" of Emacs is 
packaged separately:

- the emacs package (which is "a metapackage that will always depend on 
the latest recommended Emacs variant") depends on emacs-gtk or emacs-lucid 
or emacs-nox (= terminal-only)

- the emacs-gtk, emacs-lucid and emacs-nox packages (which contain the 
Emacs binary and corresponding pdmp files) all depend on on 
emacs-bin-common and emacs-common, and suggest emacs-common-non-dfsg

- the emacs-bin-common package (which contains the ctags, ebrowse, 
emacsclient, etags, hexl and rcs2log binaries) depends on emacs-common

- the emacs-common package (which contains the etc/ directory and the elc 
files) recommends emacs-el and suggests emacs-common-non-dfsg

- the emacs-el package contains the el files

- the emacs-common-non-dfsg contains the info files

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dima Kogan <dima@secretsauce.net>
>> Date: Tue, 11 May 2021 01:44:03 -0700
>> Cc: 48342@debbugs.gnu.org
>> 
>> Andrea Corallo <akrl@sdf.org> writes:
>> 
>> > could you share the Lisp backtrace? If you have loaded the .gdbinit
>> > shipped with the repot this will be at the bottom of the gdb
>> > backtrace.
>> 
>> Hi Andrea. The backtrace looks like this:
>> 
>>   "display-warning" (0xffebcfd8)
>>   "display-warning" (0xffebd5d8)
>>   "display-warning" (0xffebdbd8)
>>   "display-warning" (0xffebe1d8)
>
> Any idea how come display-warning calls itself?

Nothing evident to me ATM.  Dima, I'd like to have a look to the full C
backtrace, would be possible to share it?

Thanks

  Andrea

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

> Any idea how come display-warning calls itself?

I'm here:

  https://github.com/emacs-mirror/emacs/commit/bb8b8d

A single recursive cycle in the C backtrace looks like this:

  #21 0x000055555573b282 in maybe_swap_for_eln (no_native=no_native@entry=false, filename=filename@entry=0x7fffffebd780, fd=fd@entry=0x7fffffebd77c, mtime=...) at lread.c:1713
  #22 0x000055555573ba5d in openp (path=0x555555d75e63, str=0x7fffeefb3a1c, suffixes=<optimized out>, storeptr=0x7fffffebd958, predicate=0x0, newer=false, no_native=false) at ../lib/stat-time.h:149
  #23 0x000055555573ed05 in Fload (file=0x7fffeefb3a1c, noerror=0x0, nomessage=0x30, nosuffix=0x0, must_suffix=<optimized out>) at lisp.h:1002
  #24 0x000055555573faef in save_match_data_load (file=0x7fffeefb3a1c, noerror=noerror@entry=0x0, nomessage=nomessage@entry=0x30, nosuffix=nosuffix@entry=0x0, must_suffix=must_suffix@entry=0x30) at lread.c:1616
  #25 0x0000555555713d57 in Fautoload_do_load (fundef=0x7fffef14ed9b, funname=0x2aaa99569808, macro_only=0x0) at eval.c:2308
  #26 0x0000555555714040 in Ffuncall (nargs=3, args=0x7fffffebdbd0) at lisp.h:1002
  #27 0x0000555555714211 in call2 (fn=<optimized out>, arg1=arg1@entry=0x4650, arg2=arg2@entry=0x555555f11bf4) at eval.c:2903
  #28 0x000055555573b282 in maybe_swap_for_eln (no_native=no_native@entry=false, filename=filename@entry=0x7fffffebdd80, fd=fd@entry=0x7fffffebdd7c, mtime=...) at lread.c:1713

The maybe_swap_for_el() call in Frame #28 checks for the sources, sees
that the file on disk doesn't exist, and throws the warning as expected:

Code:
  call2 (intern_c_string ("display-warning")
Full context:
  https://github.com/emacs-mirror/emacs/blob/bb8b8d717f91a85ca41de9e82246e6975e1ed719/src/lread.c#L1713

Frame #26 is the (display-warning ...)

Frame #25 is (autoload-do-load ... 'display-warning)

Frame #23 is (load "warnings" ...)

The backtrace isn't right about the line number in frame #22, but that
function is in lread.c. It's trying to compile "warnings.el".


> Note that if you will be distributing the *.eln files, I think the GPL
> requires you to make the *.el files available. In fact, this is so
> even with the *.elc files. So I'm not sure I understand how you could
> distribute only the *.elc files until now: isn't that contrary to GPL?

The .el files are available, but the user doesn't have to install them.
Just like the .c sources are available, but the user can install just
the pre-built binaries if they want to.

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: akrl@sdf.org, 48342@debbugs.gnu.org
> Date: Tue, 11 May 2021 10:29:20 -0700
> 
> > Note that if you will be distributing the *.eln files, I think the GPL
> > requires you to make the *.el files available. In fact, this is so
> > even with the *.elc files. So I'm not sure I understand how you could
> > distribute only the *.elc files until now: isn't that contrary to GPL?
> 
> The .el files are available, but the user doesn't have to install them.
> Just like the .c sources are available, but the user can install just
> the pre-built binaries if they want to.

That's a problematic interpretation of the GPL, IME: this way, how can
the user be sure he/she will be able to obtain at a later date the
sources of the exact binary he/she is running?  And the same question
for Lisp files and the corresponding *.elc/*.eln.  The only way to
make sure is to have them together.

But I don't intend to argue more about that.

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

>> > Note that if you will be distributing the *.eln files, I think the GPL
>> > requires you to make the *.el files available. In fact, this is so
>> > even with the *.elc files. So I'm not sure I understand how you could
>> > distribute only the *.elc files until now: isn't that contrary to GPL?
>> 
>> The .el files are available, but the user doesn't have to install them.
>> Just like the .c sources are available, but the user can install just
>> the pre-built binaries if they want to.
>
> That's a problematic interpretation of the GPL, IME: this way, how can
> the user be sure he/she will be able to obtain at a later date the
> sources of the exact binary he/she is running?  And the same question
> for Lisp files and the corresponding *.elc/*.eln.  The only way to
> make sure is to have them together.

Debian (an every other distro I'm guessing) has been doing it like this
for a really long time. Everything is versioned. When the distributor
makes packages, they build and ship all the packages together: sources,
binaries, .el, .elc, and so on.

When a user installs the packages at a later time, they don't have to
download and install the whole set. A user installs "emacs" version
"abc". The version string includes the upstream version that select a
specific emacs release AND the packaging version. At any later point in
time the user can install "emacs-el" version "abc" or get the sources
for emacs, again at version "abc". The identical version numbers
guarantee that they're downloading packages the distributor built at the
same time as the "emacs" package the user has already. It works.

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Gregory Heytings]

>> That's a problematic interpretation of the GPL, IME: this way, how can 
>> the user be sure he/she will be able to obtain at a later date the 
>> sources of the exact binary he/she is running?  And the same question 
>> for Lisp files and the corresponding *.elc/*.eln.  The only way to make 
>> sure is to have them together.
>
> Debian (an every other distro I'm guessing) has been doing it like this 
> for a really long time. Everything is versioned. When the distributor 
> makes packages, they build and ship all the packages together: sources, 
> binaries, .el, .elc, and so on.
>
> When a user installs the packages at a later time, they don't have to 
> download and install the whole set. A user installs "emacs" version 
> "abc". The version string includes the upstream version that select a 
> specific emacs release AND the packaging version. At any later point in 
> time the user can install "emacs-el" version "abc" or get the sources 
> for emacs, again at version "abc". The identical version numbers 
> guarantee that they're downloading packages the distributor built at the 
> same time as the "emacs" package the user has already. It works.
>

I think that doesn't completely answer Eli's question: "how can the user 
be sure he/she will be able to obtain at a later date the sources of the 
exact binary he/she is running?"

Debian at least maintains a separate repository (snapshot.debian.org) in 
which you can find each version of each package distributed by Debian 
after March 2005, in both source and binary form.  Yes, that's quite a lot 
of data: that archive currently occupies ~100 TB.

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Eli Zaretskii]

> Date: Tue, 11 May 2021 18:57:32 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Eli Zaretskii <eliz@gnu.org>, 48342@debbugs.gnu.org, akrl@sdf.org
> 
> Debian at least maintains a separate repository (snapshot.debian.org) in 
> which you can find each version of each package distributed by Debian 
> after March 2005, in both source and binary form.  Yes, that's quite a lot 
> of data: that archive currently occupies ~100 TB.

My concern is about users who still have Emacs before March 2005.

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Gregory Heytings]

>> Debian at least maintains a separate repository (snapshot.debian.org) 
>> in which you can find each version of each package distributed by 
>> Debian after March 2005, in both source and binary form.  Yes, that's 
>> quite a lot of data: that archive currently occupies ~100 TB.
>
> My concern is about users who still have Emacs before March 2005.
>

I forgot to mention that snapshot.debian.org also contains a copy of all 
earlier stable releases of Debian since ~1995.  For Emacs, the oldest 
version in that archive is Emacs 19.29...

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Eli Zaretskii]

> Date: Tue, 11 May 2021 19:38:30 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: dima@secretsauce.net, 48342@debbugs.gnu.org, akrl@sdf.org
> 
> > My concern is about users who still have Emacs before March 2005.
> 
> I forgot to mention that snapshot.debian.org also contains a copy of all 
> earlier stable releases of Debian since ~1995.

Imagine the plight of a user who needs to discover all these places
just to have the sources available.

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Dima Kogan]

Eli Zaretskii <eliz@gnu.org> writes:

> Imagine the plight of a user who needs to discover all these places
> just to have the sources available.

I suppose you have a point, but this concern is much bigger than just
emacs. A user of a binary distro (pretty much all of them) may have a
binary package installed (anything; not just emacs), and could go
looking for sources many decades later. These are available, but will
take some work to find if you wait that long. Fixing this is a large
battle, and I'm not convinced it's worth fighting.

For Debian specifically, the snapshot.debian.org repos Gregory mentioned
are primarily useful to people that use the unstable packages. The
official, released, packages live in more standard locations, and should
be easier to get, even decades later. I say "should" because this is not
a common need, and I never went looking myself.

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: Gregory Heytings <gregory@heytings.org>, 48342@debbugs.gnu.org,
>  akrl@sdf.org
> Date: Tue, 11 May 2021 12:59:27 -0700
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Imagine the plight of a user who needs to discover all these places
> > just to have the sources available.
> 
> I suppose you have a point, but this concern is much bigger than just
> emacs.

That there's a larger problem out there doesn't mean we shouldn't
strive to get our act together in our small corner.  It isn't a
justification, not IMO anyway.

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Gregory Heytings]

>>> My concern is about users who still have Emacs before March 2005.
>>
>> I forgot to mention that snapshot.debian.org also contains a copy of 
>> all earlier stable releases of Debian since ~1995.
>
> Imagine the plight of a user who needs to discover all these places just 
> to have the sources available.
>

As Dima said, the same would be true for the C sources.  And, for Debian 
at least, it's not that difficult: from 
https://snapshot.debian.org/binary/emacs you can easily find every binary 
and source file you might need.  I cannot imagine a system that would be 
significantly simpler.

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Gregory Heytings]

>
> And, for Debian at least, it's not that difficult: from 
> https://snapshot.debian.org/binary/emacs
>

I meant: https://snapshot.debian.org/binary/emacs/

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Eli Zaretskii]

> From: Dima Kogan <dima@secretsauce.net>
> Cc: akrl@sdf.org, 48342@debbugs.gnu.org
> Date: Tue, 11 May 2021 10:29:20 -0700
> 
> The maybe_swap_for_el() call in Frame #28 checks for the sources, sees
> that the file on disk doesn't exist, and throws the warning as expected:
> 
> Code:
>   call2 (intern_c_string ("display-warning")
> Full context:
>   https://github.com/emacs-mirror/emacs/blob/bb8b8d717f91a85ca41de9e82246e6975e1ed719/src/lread.c#L1713
> 
> Frame #26 is the (display-warning ...)
> 
> Frame #25 is (autoload-do-load ... 'display-warning)
> 
> Frame #23 is (load "warnings" ...)
> 
> The backtrace isn't right about the line number in frame #22, but that
> function is in lread.c. It's trying to compile "warnings.el".

I guess when we find that a source for some .elc file is not
available, we should add its .el name to
native-comp-deferred-compilation-deny-list?

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Dima Kogan <dima@secretsauce.net>
>> Cc: akrl@sdf.org, 48342@debbugs.gnu.org
>> Date: Tue, 11 May 2021 10:29:20 -0700
>> 
>> The maybe_swap_for_el() call in Frame #28 checks for the sources, sees
>> that the file on disk doesn't exist, and throws the warning as expected:
>> 
>> Code:
>>   call2 (intern_c_string ("display-warning")
>> Full context:
>>   https://github.com/emacs-mirror/emacs/blob/bb8b8d717f91a85ca41de9e82246e6975e1ed719/src/lread.c#L1713
>> 
>> Frame #26 is the (display-warning ...)
>> 
>> Frame #25 is (autoload-do-load ... 'display-warning)
>> 
>> Frame #23 is (load "warnings" ...)
>> 
>> The backtrace isn't right about the line number in frame #22, but that
>> function is in lread.c. It's trying to compile "warnings.el".
>
> I guess when we find that a source for some .elc file is not
> available, we should add its .el name to
> native-comp-deferred-compilation-deny-list?

Good idea that's probably the best fix.  I'll come-up with a patch for
this.

Thanks

  Andrea

bug#48342: native-comp emacs gets into an infinite loop at startup if no .el files are available

[Lars Ingebrigtsen]

Andrea Corallo <akrl@sdf.org> writes:

>> I guess when we find that a source for some .elc file is not
>> available, we should add its .el name to
>> native-comp-deferred-compilation-deny-list?
>
> Good idea that's probably the best fix.  I'll come-up with a patch for
> this.

I did an even simpler fix in Emacs 29 -- if we're in an Emacs without
.el files, I make maybe_swap_for_eln disable the warning, and that seems
to fix the issue.  (I check for "simple.el" -- if we don't have that,
then we probably don't have any .el files.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no