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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 48342 in the body.
You can then email your comments to 48342 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Dima Kogan <dima <at> secretsauce.net>
To: bug-gnu-emacs <at> gnu.org
Subject: native-comp emacs gets into an infinite loop at startup if no .el
 files are available
Date: Tue, 11 May 2021 00:47:10 -0700

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!

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 48342 <at> debbugs.gnu.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 08:37:01 +0000

Dima Kogan <dima <at> 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

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

From: Dima Kogan <dima <at> secretsauce.net>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: 48342 <at> debbugs.gnu.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 01:44:03 -0700

Andrea Corallo <akrl <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 48342 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 15:33:28 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Date: Tue, 11 May 2021 01:44:03 -0700
> Cc: 48342 <at> debbugs.gnu.org
> 
> Andrea Corallo <akrl <at> 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?

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Dima Kogan <dima <at> secretsauce.net>, 48342 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 17:00:46 +0000

>>> 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

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Dima Kogan <dima <at> secretsauce.net>, 48342 <at> debbugs.gnu.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 17:12:36 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Dima Kogan <dima <at> secretsauce.net>
>> Date: Tue, 11 May 2021 01:44:03 -0700
>> Cc: 48342 <at> debbugs.gnu.org
>> 
>> Andrea Corallo <akrl <at> 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

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

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48342 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 10:29:20 -0700

Eli Zaretskii <eliz <at> 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 <at> entry=false, filename=filename <at> entry=0x7fffffebd780, fd=fd <at> 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 <at> entry=0x0, nomessage=nomessage <at> entry=0x30, nosuffix=nosuffix <at> entry=0x0, must_suffix=must_suffix <at> 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 <at> entry=0x4650, arg2=arg2 <at> entry=0x555555f11bf4) at eval.c:2903
  #28 0x000055555573b282 in maybe_swap_for_eln (no_native=no_native <at> entry=false, filename=filename <at> entry=0x7fffffebdd80, fd=fd <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 48342 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 20:43:28 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: akrl <at> sdf.org, 48342 <at> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: 48342 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 20:45:43 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: akrl <at> sdf.org, 48342 <at> 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?

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

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 48342 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 10:57:03 -0700

Eli Zaretskii <eliz <at> 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.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 48342 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 18:57:32 +0000

>> 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.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: dima <at> secretsauce.net, 48342 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 22:11:38 +0300

> Date: Tue, 11 May 2021 18:57:32 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: Eli Zaretskii <eliz <at> gnu.org>, 48342 <at> debbugs.gnu.org, akrl <at> 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.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dima <at> secretsauce.net, 48342 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 19:38:30 +0000

>> 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...

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Dima Kogan <dima <at> secretsauce.net>, 48342 <at> debbugs.gnu.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 19:43:21 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Dima Kogan <dima <at> secretsauce.net>
>> Cc: akrl <at> sdf.org, 48342 <at> 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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gregory Heytings <gregory <at> heytings.org>
Cc: dima <at> secretsauce.net, 48342 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 22:51:39 +0300

> Date: Tue, 11 May 2021 19:38:30 +0000
> From: Gregory Heytings <gregory <at> heytings.org>
> cc: dima <at> secretsauce.net, 48342 <at> debbugs.gnu.org, akrl <at> 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.

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

From: Dima Kogan <dima <at> secretsauce.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Gregory Heytings <gregory <at> heytings.org>, 48342 <at> debbugs.gnu.org,
 akrl <at> sdf.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 12:59:27 -0700

Eli Zaretskii <eliz <at> 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.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dima <at> secretsauce.net, 48342 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 20:00:37 +0000

>>> 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.

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

From: Gregory Heytings <gregory <at> heytings.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dima <at> secretsauce.net, 48342 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 20:04:37 +0000

>
> 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/

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dima Kogan <dima <at> secretsauce.net>
Cc: gregory <at> heytings.org, 48342 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Tue, 11 May 2021 23:23:53 +0300

> From: Dima Kogan <dima <at> secretsauce.net>
> Cc: Gregory Heytings <gregory <at> heytings.org>, 48342 <at> debbugs.gnu.org,
>  akrl <at> sdf.org
> Date: Tue, 11 May 2021 12:59:27 -0700
> 
> Eli Zaretskii <eliz <at> 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.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Dima Kogan <dima <at> secretsauce.net>,
 48342 <at> debbugs.gnu.org
Subject: Re: bug#48342: native-comp emacs gets into an infinite loop at
 startup if no .el files are available
Date: Sat, 02 Jul 2022 18:44:35 +0200

Andrea Corallo <akrl <at> 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

Previous Next

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