unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Michael Welsh Duggan <mwd@md5i.com>, Andrea Corallo <akrl@sdf.org>
Cc: Alan Mackenzie <acm@muc.de>, 48446@debbugs.gnu.org
Subject: bug#48446: 28.0.50; Native compile failure during bootstrap
Date: Sat, 15 May 2021 20:17:00 +0300	[thread overview]
Message-ID: <83im3jx6gj.fsf@gnu.org> (raw)
In-Reply-To: <87tun4osqg.fsf@md5i.com> (message from Michael Welsh Duggan on Sat, 15 May 2021 12:40:39 -0400)

> From: Michael Welsh Duggan <mwd@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





  reply	other threads:[~2021-05-15 17:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-15 16:40 bug#48446: 28.0.50; Native compile failure during bootstrap Michael Welsh Duggan
2021-05-15 17:17 ` Eli Zaretskii [this message]
2021-05-15 18:08   ` Eli Zaretskii
2021-05-15 18:21     ` Eli Zaretskii
2021-05-16  8:00       ` Andrea Corallo via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-05-16  9:01         ` Eli Zaretskii
2021-05-16  5:22     ` Michael Welsh Duggan
2021-05-16  5:31       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83im3jx6gj.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=48446@debbugs.gnu.org \
    --cc=acm@muc.de \
    --cc=akrl@sdf.org \
    --cc=mwd@md5i.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public 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).