From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: jm@pub.pink, 68690@debbugs.gnu.org
Subject: bug#68690: Segmentation fault building with native-comp
Date: Thu, 25 Jan 2024 21:43:01 -0500 [thread overview]
Message-ID: <jwvo7d8lt3d.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <86le8dd7ze.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 25 Jan 2024 12:26:29 +0200")
>> Hmm... I can't reproduce it here (even with native-comp and
>> `--with-wide-int`).
> This build is without native-comp, but it's a 32-bit build. Did you
> try that? I think that's the key to unlock this (see below).
I tried 32bit with and without native-comp, and with and without wide-int,
but can't reproduce it here. Maybe it only manifest itself under w32?
In your message I see it crashes compiling `mwheel.el`; is that the
first place where it crashes? Does it crash on most other files as
well? In interactive use?
>> The above stack frame suggests it might be related
>> to commit 33b8d5b6c5a (and hence unrelated to the original bug#68690
>> which was a bug in `DOHASH`).
>> Any chance you can investigate what is this `0x92348b000000000`?
> It's obviously a bogus value, since Lisp objects in this build should
> have their high 32 bits zero except for the type tag in the MSBs.
Indeed.
>> It should be a charset's attributes and the "idx=1" is because
>> we're using `CHARSET_ATTR_NAME` to extract the name.
> It sounds like we are not dumping the charset attributes correctly,
> and that also corrupts all the fields of a struct charset following
> the attributes. Here's this charset in temacs:
[...]
> (gdb) p cs->attributes
> $3 = XIL(0xa000000009023d88)
[...]
> And here's the same charset in emacs, after we restore from dump:
[...]
> attributes = XIL(0x92848b000000000),
Yup, sure looks like the bytes got shifted by 4 bytes for some reason.
> I tried to figure out what is wrong with how we dump this new field,
> but got lost in the proverbial twisty little passages of pdumper.c,
> all alike.
🙁
> For example, I cannot understand why some fields which are
> Lisp objects are dumped with dump_field_lv while others with
> dump_field_lv_or_rawptr, and what is the significance of WEIGHT_NORMAL
> vs WEIGHT_STRONG. Hopefully, the above gives enough information for
> you to figure this out.
I'm just as lost as you are in pdumper.c, sadly.
Stefan
next prev parent reply other threads:[~2024-01-26 2:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-24 14:36 bug#68690: Segmentation fault building with native-comp john muhl via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-24 17:10 ` Eli Zaretskii
2024-01-24 19:52 ` Gerd Möllmann
2024-01-24 19:56 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-24 20:27 ` Eli Zaretskii
2024-01-24 23:59 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-25 10:26 ` Eli Zaretskii
2024-01-26 2:43 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]
2024-01-26 8:40 ` Eli Zaretskii
2024-01-26 9:26 ` Gerd Möllmann
2024-01-26 13:48 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-26 14:36 ` Eli Zaretskii
2024-01-26 15:51 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-26 14:30 ` Eli Zaretskii
2024-01-26 14:47 ` Gerd Möllmann
2024-01-26 14:55 ` Eli Zaretskii
2024-01-27 0:08 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-27 4:07 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-27 7:50 ` Eli Zaretskii
2024-01-27 14:45 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-26 10:18 ` Andreas Schwab
2024-01-26 13:49 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-26 14:50 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-25 5:33 ` Gerd Möllmann
2024-01-25 8:33 ` Gerd Möllmann
2024-01-25 15:58 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-25 18:12 ` Mattias Engdegård
2024-01-25 22:39 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-26 16:07 ` Mattias Engdegård
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=jwvo7d8lt3d.fsf-monnier+emacs@gnu.org \
--to=bug-gnu-emacs@gnu.org \
--cc=68690@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=jm@pub.pink \
--cc=monnier@iro.umontreal.ca \
/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.