bug#68690: Segmentation fault building with native-comp

[Stefan Monnier]

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