GNU bug report logs - #68690
Segmentation fault building with native-comp

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: jm <at> pub.pink, 68690 <at> debbugs.gnu.org
Subject: bug#68690: Segmentation fault building with native-comp
Date: Thu, 25 Jan 2024 21:43:01 -0500

>> 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

Previous Next

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