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
next prev parent 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
* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.