GNU bug report logs - #48446
28.0.50; Native compile failure during bootstrap

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 48446 in the body.
You can then email your comments to 48446 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: Michael Welsh Duggan <mwd <at> md5i.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; Native compile failure during bootstrap
Date: Sat, 15 May 2021 12:40:39 -0400

[Message part 1 (text/plain, inline)]

I'm attempting to build the native compile using NATIVE_FULL_AOT=1 from
the master branch  from scratch.  I'm building from repository revision
46e4704e2abca4d264a43965f92eab7608211ee6.

During the final elisp compilation phase the process segfaults.

I've attached my config.log and the make output.  I'm using libgccjit
version 10.2.1-6 from Debian unstable.

[config.log (text/plain, attachment)]

[make.log (text/plain, attachment)]

[Message part 4 (text/plain, inline)]

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Welsh Duggan <mwd <at> md5i.com>, Andrea Corallo <akrl <at> sdf.org>
Cc: Alan Mackenzie <acm <at> muc.de>, 48446 <at> debbugs.gnu.org
Subject: Re: bug#48446: 28.0.50; Native compile failure during bootstrap
Date: Sat, 15 May 2021 20:17:00 +0300

> From: Michael Welsh Duggan <mwd <at> md5i.com>
> Date: Sat, 15 May 2021 12:40:39 -0400
> 
> I'm attempting to build the native compile using NATIVE_FULL_AOT=1 from
> the master branch  from scratch.  I'm building from repository revision
> 46e4704e2abca4d264a43965f92eab7608211ee6.
> 
> During the final elisp compilation phase the process segfaults.
> 
> I've attached my config.log and the make output.  I'm using libgccjit
> version 10.2.1-6 from Debian unstable.

This seems to be due to the call to minibuffer-inactive-mode at
startup.

Andrea, can you help here?  The problem is in set_minibuffer_mode,
which is called from init_minibuf_once_for_pdumper:

  static void
  set_minibuffer_mode (Lisp_Object buf, EMACS_INT depth)
  {
    ptrdiff_t count = SPECPDL_INDEX ();

    record_unwind_current_buffer ();
    Fset_buffer (buf);
    if (depth > 0)
      {
	if (!NILP (Ffboundp (Qminibuffer_mode)))
	  call0 (Qminibuffer_mode);
      }
    else
      {
	if (!NILP (Ffboundp (Qminibuffer_inactive_mode)))
	  call0 (Qminibuffer_inactive_mode);  <<<<<<<<<<<<<<<<<<<<<<<<<<
	else
	  Fkill_all_local_variables ();
      }
    buf = unbind_to (count, buf);
  }

In this call, I see the following backtrace:

  Program received signal SIGSEGV, Segmentation fault.
  0x00000000 in ?? ()
  (gdb) bt
  #0  0x00000000 in ?? ()
  #1  0x01261804 in funcall_subr (subr=0x5cfb174, numargs=0, args=0x82f510)
      at eval.c:3109
  #2  0x01261294 in Ffuncall (nargs=1, args=0x82f508) at eval.c:3036
  #3  0x0126055c in call0 (fn=XIL(0xa6e0)) at eval.c:2889
  #4  0x011c423e in set_minibuffer_mode (buf=XIL(0xa0000000060e0414), depth=0)
      at minibuf.c:998
  #5  0x011c9846 in init_minibuf_once_for_pdumper () at minibuf.c:2301
  #6  0x0122bd60 in pdumper_load (
      dump_filename=0xfc1f80 "D:\\gnu\\git\\emacs\\native-comp\\src\\emacs.pdmp",argv0=0xfc1f38 "D:\\gnu\\git\\emacs\\native-comp\\src\\emacs.exe")
      at pdumper.c:5668
  #7  0x0115d674 in load_pdump (argc=11, argv=0xa442c0) at emacs.c:901
  #8  0x0115dd57 in main (argc=11, argv=0xa442c0) at emacs.c:1306

  Lisp Backtrace:
  "minibuffer-inactive-mode" (0x82f510)
  (gdb) fr 1
  #1  0x01261804 in funcall_subr (subr=0x5cfb174, numargs=0, args=0x82f510)
      at eval.c:3109
  3109              return (subr->function.a0 ());
  (gdb) p subr->function.a0
  $1 = (Lisp_Object (*)(void)) 0x0

Note that subr->function.a0 is a NULL pointer, which is why it
crashes.  Here's the subr->function object in its entirety:

  (gdb) fr 1
  #1  0x01261804 in funcall_subr (subr=0x5cfb174, numargs=0, args=0x82f510)
      at eval.c:3109
  3109              return (subr->function.a0 ());
  (gdb) p subr
  $7 = (struct Lisp_Subr *) 0x5cfb174
  (gdb) p *subr
  $8 = {
    header = {
      size = 1342205952
    },
    function = {
      a0 = 0x0,
      a1 = 0x0,
      a2 = 0x0,
      a3 = 0x0,
      a4 = 0x0,
      a5 = 0x0,
      a6 = 0x0,
      a7 = 0x0,
      a8 = 0x0,
      aUNEVALLED = 0x0,
      aMANY = 0x0
    },
    min_args = 0,
    max_args = 0,
    symbol_name = 0x628fb24 "minibuffer-inactive-mode",
    {
      intspec = 0x5cfb1b4 "@ז",
      native_intspec = XIL(0xc000000005cfb1b4)
    },
    doc = 146,
    native_comp_u = {XIL(0xa000000005a97cbc)},
    native_c_name = {
      0x628fb3d "F6d696e696275666665722d696e6163746976652d6d6f6465_minibuffer_inactive_mode_0"},
    lambda_list = {XIL(0)},
    type = {XIL(0xc000000005a71394)}
  }

As you see, the native_comp_u member is non-NULL.  But still Ffuncall
called funcall_subr, which AFAIU means it thought that
Qminibuffer_inactive_mode is not a natively-compiled function.

What are we missing in this case? why doesn't Emacs recognize
Qminibuffer_inactive_mode as a natively-compiled function?  Is this
too early during startup, and if so, how to we call Lisp at this
stage?

TIA

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: mwd <at> md5i.com, akrl <at> sdf.org
Cc: acm <at> muc.de, 48446 <at> debbugs.gnu.org
Subject: Re: bug#48446: 28.0.50; Native compile failure during bootstrap
Date: Sat, 15 May 2021 21:08:14 +0300

> Date: Sat, 15 May 2021 20:17:00 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: Alan Mackenzie <acm <at> muc.de>, 48446 <at> debbugs.gnu.org
> 
> As you see, the native_comp_u member is non-NULL.  But still Ffuncall
> called funcall_subr, which AFAIU means it thought that
> Qminibuffer_inactive_mode is not a natively-compiled function.
> 
> What are we missing in this case? why doesn't Emacs recognize
> Qminibuffer_inactive_mode as a natively-compiled function?  Is this
> too early during startup, and if so, how to we call Lisp at this
> stage?

I think I succeeded to fix this now, but I'd still like to know
why the original code was wrong and how to avoid that in the future.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: akrl <at> sdf.org
Cc: mwd <at> md5i.com, acm <at> muc.de, 48446 <at> debbugs.gnu.org
Subject: Re: bug#48446: 28.0.50; Native compile failure during bootstrap
Date: Sat, 15 May 2021 21:21:04 +0300

> Date: Sat, 15 May 2021 21:08:14 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: acm <at> muc.de, 48446 <at> debbugs.gnu.org
> 
> I think I succeeded to fix this now, but I'd still like to know
> why the original code was wrong and how to avoid that in the future.

I think I know the answer: with natively-compiled Lisp, we can only
call Lisp from init functions registered with
pdumper_do_now_and_after_late_load, because the *.eln files are not
loaded when functions registered with pdumper_do_now_and_after_load
are run.  Andrea, is that conclusion correct?

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

From: Michael Welsh Duggan <mwd <at> md5i.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mwd <at> md5i.com, acm <at> muc.de, 48446 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48446: 28.0.50; Native compile failure during bootstrap
Date: Sun, 16 May 2021 01:22:32 -0400

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

>> Date: Sat, 15 May 2021 20:17:00 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: Alan Mackenzie <acm <at> muc.de>, 48446 <at> debbugs.gnu.org
>> 
>> As you see, the native_comp_u member is non-NULL.  But still Ffuncall
>> called funcall_subr, which AFAIU means it thought that
>> Qminibuffer_inactive_mode is not a natively-compiled function.
>> 
>> What are we missing in this case? why doesn't Emacs recognize
>> Qminibuffer_inactive_mode as a natively-compiled function?  Is this
>> too early during startup, and if so, how to we call Lisp at this
>> stage?
>
> I think I succeeded to fix this now, but I'd still like to know
> why the original code was wrong and how to avoid that in the future.

Your further questions are surely worth getting answered, but I can
attest that your patch solves this problem for me.  Thank you!

-- 
Michael Welsh Duggan
(md5i <at> md5i.com)

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Welsh Duggan <mwd <at> md5i.com>
Cc: acm <at> muc.de, 48446 <at> debbugs.gnu.org, akrl <at> sdf.org
Subject: Re: bug#48446: 28.0.50; Native compile failure during bootstrap
Date: Sun, 16 May 2021 08:31:56 +0300

> From: Michael Welsh Duggan <mwd <at> md5i.com>
> Cc: mwd <at> md5i.com,  akrl <at> sdf.org,  acm <at> muc.de,  48446 <at> debbugs.gnu.org
> Date: Sun, 16 May 2021 01:22:32 -0400
> 
> > I think I succeeded to fix this now, but I'd still like to know
> > why the original code was wrong and how to avoid that in the future.
> 
> Your further questions are surely worth getting answered, but I can
> attest that your patch solves this problem for me.  Thank you!

Thanks for testing.

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

From: Andrea Corallo <akrl <at> sdf.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mwd <at> md5i.com, acm <at> muc.de, 48446 <at> debbugs.gnu.org
Subject: Re: bug#48446: 28.0.50; Native compile failure during bootstrap
Date: Sun, 16 May 2021 08:00:42 +0000

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

>> Date: Sat, 15 May 2021 21:08:14 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> Cc: acm <at> muc.de, 48446 <at> debbugs.gnu.org
>> 
>> I think I succeeded to fix this now, but I'd still like to know
>> why the original code was wrong and how to avoid that in the future.
>
> I think I know the answer: with natively-compiled Lisp, we can only
> call Lisp from init functions registered with
> pdumper_do_now_and_after_late_load, because the *.eln files are not
> loaded when functions registered with pdumper_do_now_and_after_load
> are run.  Andrea, is that conclusion correct?

AFAIR that is spot on, I've introduced the mechanism with 4fba79feee.

Thanks for fixing this.

  Andrea

Message #28 received at 48446-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andrea Corallo <akrl <at> sdf.org>
Cc: mwd <at> md5i.com, acm <at> muc.de, 48446-done <at> debbugs.gnu.org
Subject: Re: bug#48446: 28.0.50; Native compile failure during bootstrap
Date: Sun, 16 May 2021 12:01:07 +0300

> From: Andrea Corallo <akrl <at> sdf.org>
> Cc: mwd <at> md5i.com, acm <at> muc.de, 48446 <at> debbugs.gnu.org
> Date: Sun, 16 May 2021 08:00:42 +0000
> 
> > I think I know the answer: with natively-compiled Lisp, we can only
> > call Lisp from init functions registered with
> > pdumper_do_now_and_after_late_load, because the *.eln files are not
> > loaded when functions registered with pdumper_do_now_and_after_load
> > are run.  Andrea, is that conclusion correct?
> 
> AFAIR that is spot on, I've introduced the mechanism with 4fba79feee.

Thanks, I'm therefore closing this bug report.

Previous Next

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