From: Eli Zaretskii <eliz@gnu.org>
To: Helmut Eller <eller.helmut@gmail.com>
Cc: gerd.moellmann@gmail.com, acorallo@gnu.org, emacs-devel@gnu.org
Subject: Re: MPS codegen
Date: Fri, 14 Jun 2024 14:32:38 +0300 [thread overview]
Message-ID: <86ikybyd2h.fsf@gnu.org> (raw)
In-Reply-To: <8734pfgb51.fsf@gmail.com> (message from Helmut Eller on Fri, 14 Jun 2024 10:51:38 +0200)
> From: Helmut Eller <eller.helmut@gmail.com>
> Cc: Andrea Corallo <acorallo@gnu.org>, Eli Zaretskii <eliz@gnu.org>,
> emacs-devel@gnu.org
> Date: Fri, 14 Jun 2024 10:51:38 +0200
>
> On Fri, Jun 14 2024, Gerd Möllmann wrote:
>
> > Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> >
> >> Helmut Eller <eller.helmut@gmail.com> writes:
> >>
> >>> I planned to give it a try, but not until somebody™ updates the branch
> >>> on savannah. Otherwise patches to pdumper.c don't apply cleanly.
> >>
> >> Ok, ok, I'll give it a try now that you did the obarray and pure space
> >> thing. No pressure :-).
> >
> > By our command. Done :-).
>
> Thanks!
Too soon to be happy: the MS-Windows 32-bit build is now broken: it
segfaults while producing loaddefs.el:
Starting program: d:\gnu\git\emacs\feature\src\emacs.exe -batch --no-site-file --no-site-lisp -l ./emacs-lisp/loaddefs-gen.elc -f loaddefs-generate--emacs-batch . ./calc ./calendar ./cedet ./cedet/ede ./cedet/semantic ./cedet/semantic/analyze ./cedet/semantic/bovine ./cedet/semantic/decorate ./cedet/semantic/symref ./cedet/semantic/wisent ./cedet/srecode ./emacs-lisp ./emulation ./erc ./eshell ./gnus ./image ./international ./language ./leim ./leim/ja-dic ./leim/quail ./mail ./mh-e ./net ./nxml ./org ./play ./progmodes ./textmodes ./url ./use-package ./vc
[New Thread 30924.0x8288]
[New Thread 30924.0x8448]
[New Thread 30924.0x87bc]
warning: Enabling Low Fragmentation Heap failed: error 87
Thread 1 received signal SIGSEGV, Segmentation fault.
do_symval_forwarding (valcontents=...) at data.c:1334
1334 switch (XFWDTYPE (valcontents))
(gdb) bt
#0 do_symval_forwarding (valcontents=...) at data.c:1334
#1 0x008a576d in specbind (symbol=<optimized out>, symbol@entry=XIL(0x53b8),
value=value@entry=XIL(0x18)) at eval.c:3572
#2 0x0073fb6e in message_dolog (m=<optimized out>, nbytes=<optimized out>,
nlflag=true, multibyte=false) at lisp.h:1191
#3 0x0074a3b0 in message_dolog (m=<optimized out>,
m@entry=0xde85d1 <b_fwd+1597> "", nbytes=nbytes@entry=0,
nlflag=nlflag@entry=true, multibyte=multibyte@entry=false) at xdisp.c:12216
#4 0x00a4c0a5 in main (argc=<optimized out>, argv=<optimized out>)
at emacs.c:2229
(gdb) fr 2
#2 0x008a576d in specbind (symbol=<optimized out>, symbol@entry=XIL(0x53b8),
value=value@entry=XIL(0x18)) at eval.c:3572
3572 Lisp_Object ovalue = find_symbol_value (symbol);
(gdb) l
3567 specpdl_ptr->let.where.kbd = NULL;
3568 break;
3569 case SYMBOL_LOCALIZED:
3570 case SYMBOL_FORWARDED:
3571 {
3572 Lisp_Object ovalue = find_symbol_value (symbol);
3573 specpdl_ptr->let.kind = SPECPDL_LET_LOCAL;
3574 specpdl_ptr->let.symbol = symbol;
3575 specpdl_ptr->let.old_value = ovalue;
3576 specpdl_ptr->let.where.buf = Fcurrent_buffer ();
(gdb) p symbol
$1 = <optimized out>
I get basically the same segfault and backtrace if I delete
loaddefs-gen.elc and run "make"; repeating the same command under GDB
produces this:
Starting program: d:\gnu\git\emacs\feature\src\emacs.exe -batch --no-site-file --no-site-lisp --eval "(setq load-prefer-newer t byte-compile-warnings 'all)" --eval "(setq org--inhibit-version-check t)" -f batch-byte-compile emacs-lisp/loaddefs-gen.el
[New Thread 30136.0x8330]
[New Thread 30136.0x81c8]
[New Thread 30136.0x843c]
warning: Enabling Low Fragmentation Heap failed: error 87
Thread 1 received signal SIGSEGV, Segmentation fault.
do_symval_forwarding (valcontents=...) at data.c:1334
1334 switch (XFWDTYPE (valcontents))
(gdb) bt
#0 do_symval_forwarding (valcontents=...) at data.c:1334
#1 0x008a576d in specbind (symbol=<optimized out>, symbol@entry=XIL(0x53b8),
value=value@entry=XIL(0x18)) at eval.c:3572
#2 0x0073fb6e in message_dolog (m=<optimized out>, nbytes=<optimized out>,
nlflag=true, multibyte=false) at lisp.h:1191
#3 0x0074a3b0 in message_dolog (m=<optimized out>,
m@entry=0xde85d1 <b_fwd+1597> "", nbytes=nbytes@entry=0,
nlflag=nlflag@entry=true, multibyte=multibyte@entry=false) at xdisp.c:12216
#4 0x00a4c0a5 in main (argc=<optimized out>, argv=<optimized out>)
at emacs.c:2229
(gdb) fr 2
#2 0x008a576d in specbind (symbol=<optimized out>, symbol@entry=XIL(0x53b8),
value=value@entry=XIL(0x18)) at eval.c:3572
3572 Lisp_Object ovalue = find_symbol_value (symbol);
(gdb) p symbol
$1 = <optimized out>
(gdb) l
3567 specpdl_ptr->let.where.kbd = NULL;
3568 break;
3569 case SYMBOL_LOCALIZED:
3570 case SYMBOL_FORWARDED:
3571 {
3572 Lisp_Object ovalue = find_symbol_value (symbol);
3573 specpdl_ptr->let.kind = SPECPDL_LET_LOCAL;
3574 specpdl_ptr->let.symbol = symbol;
3575 specpdl_ptr->let.old_value = ovalue;
3576 specpdl_ptr->let.where.buf = Fcurrent_buffer ();
(gdb) p sym
$2 = (struct Lisp_Symbol *) 0xee7f98 <lispsym+21432>
(gdb) p *$
$3 = {
u = {
s = {
gcmarkbit = 0,
redirect = SYMBOL_FORWARDED,
trapped_write = SYMBOL_UNTRAPPED_WRITE,
interned = SYMBOL_INTERNED_IN_INITIAL_OBARRAY,
declared_special = 1,
pinned = 0,
name = XIL(0xc0dbaa4),
val = {
value = XIL(0x1a986958),
alias = 0x1a986958,
blv = 0x1a986958,
fwd = {
fwdptr = 0x1a986958
}
},
function = XIL(0),
plist = XIL(0xc0dbabb),
next = 0x0
},
gcaligned = -58 'Æ'
}
}
(gdb) p $->name
There is no member named name.
(gdb) p $->u.s.name
$4 = XIL(0xc0dbaa4)
(gdb) xtype
Lisp_String
(gdb) xstring
$5 = (struct Lisp_String *) 0xc0dbaa0
"inhibit-modification-hooks"
(gdb) p $->u.s.val
There is no member named val.
(gdb) p $2->u.s.val
$6 = {
value = XIL(0x1a986958),
alias = 0x1a986958,
blv = 0x1a986958,
fwd = {
fwdptr = 0x1a986958
}
}
(gdb) p $2->u.s.val.value
$7 = XIL(0x1a986958)
(gdb) xtype
Lisp_Symbol
(gdb) xsymbol
$8 = (struct Lisp_Symbol *) 0x1b869538
Cannot access memory at address 0x1b86953c
(gdb)
Any ideas or suggestions? Does the current branch build on GNU/Linus
as a 32-bit executable?
next prev parent reply other threads:[~2024-06-14 11:32 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-10 13:39 MPS: Update Gerd Möllmann
2024-06-10 16:17 ` Andrea Corallo
2024-06-10 16:26 ` Gerd Möllmann
2024-06-10 16:44 ` Gerd Möllmann
2024-06-10 20:58 ` Andrea Corallo
2024-06-11 3:12 ` Gerd Möllmann
2024-06-11 20:35 ` Helmut Eller
2024-06-12 4:45 ` Gerd Möllmann
2024-06-12 7:54 ` Eli Zaretskii
2024-06-12 8:00 ` Gerd Möllmann
2024-06-13 9:07 ` MPS codegen (was: MPS: Update) Helmut Eller
2024-06-13 12:33 ` MPS codegen Gerd Möllmann
2024-06-13 17:48 ` Helmut Eller
2024-06-13 18:24 ` Gerd Möllmann
2024-06-13 18:31 ` Gerd Möllmann
2024-06-13 18:38 ` Helmut Eller
2024-06-13 18:54 ` Gerd Möllmann
2024-06-13 19:15 ` Helmut Eller
2024-06-13 19:37 ` Gerd Möllmann
2024-06-14 6:37 ` Eli Zaretskii
2024-06-14 7:30 ` Gerd Möllmann
2024-06-14 7:56 ` Gerd Möllmann
2024-06-14 10:52 ` Eli Zaretskii
2024-06-14 10:46 ` Eli Zaretskii
2024-06-13 23:09 ` Andrea Corallo
2024-06-14 6:08 ` Gerd Möllmann
2024-06-14 7:45 ` Helmut Eller
2024-06-14 7:59 ` Gerd Möllmann
2024-06-14 8:28 ` Gerd Möllmann
2024-06-14 8:51 ` Helmut Eller
2024-06-14 11:32 ` Eli Zaretskii [this message]
2024-06-14 12:43 ` Gerd Möllmann
2024-06-14 13:04 ` Eli Zaretskii
2024-06-14 13:17 ` Gerd Möllmann
2024-06-14 13:46 ` Eli Zaretskii
2024-06-14 14:05 ` Gerd Möllmann
2024-06-14 14:33 ` Eli Zaretskii
2024-06-14 14:46 ` Gerd Möllmann
2024-06-14 16:30 ` Helmut Eller
2024-06-14 18:28 ` Eli Zaretskii
2024-06-14 19:03 ` Eli Zaretskii
2024-06-14 19:26 ` Helmut Eller
2024-06-14 19:50 ` Gerd Möllmann
2024-06-15 6:26 ` Eli Zaretskii
2024-06-15 7:10 ` Gerd Möllmann
2024-06-15 7:34 ` Eli Zaretskii
2024-06-15 8:22 ` Gerd Möllmann
2024-06-15 6:11 ` Eli Zaretskii
2024-06-15 7:25 ` Gerd Möllmann
2024-06-15 7:46 ` Eli Zaretskii
2024-06-15 8:14 ` Gerd Möllmann
2024-06-15 8:38 ` Gerd Möllmann
2024-06-15 8:44 ` Helmut Eller
2024-06-15 8:56 ` Gerd Möllmann
2024-06-15 9:07 ` Helmut Eller
2024-06-15 9:27 ` Gerd Möllmann
2024-06-15 12:33 ` Gerd Möllmann
2024-06-16 6:16 ` Gerd Möllmann
2024-06-16 7:53 ` Eli Zaretskii
2024-06-16 8:19 ` Gerd Möllmann
2024-06-16 8:40 ` Helmut Eller
2024-06-16 8:49 ` Gerd Möllmann
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=86ikybyd2h.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=acorallo@gnu.org \
--cc=eller.helmut@gmail.com \
--cc=emacs-devel@gnu.org \
--cc=gerd.moellmann@gmail.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.