bug#68690: Segmentation fault building with native-comp

[Eli Zaretskii <eliz@gnu.org>]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  jm@pub.pink,  68690@debbugs.gnu.org
> Date: Fri, 26 Jan 2024 10:26:00 +0100
> 
> Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs@gnu.org> writes:
> 
> > I'm just as lost as you are in pdumper.c, sadly.
> 
> I remembered seeing something in pdumper.c that could be related, namely
> 
>   /* Start the cold section.  This section contains bytes that should
>      never change and so can be direct-mapped from the dump without
>      special processing.  */
>   dump_drain_cold_data (ctx);
> 
> And if you follow that function you'll see that it treats charsets
> specially.

AFAIU, that special handling is for dumping fields that are pointers.
For example, the string data in a Lisp string, buffer text in a
buffer, and the data pointed to by code_space_mask in a charset.

But the charset's attributes are not a pointer, they are a Lisp
vector.

Moreover, the offending charset (ID = 0) is not processed by
dump_cold_charset because its code_space_mask is NULL (which makes
sense since the dimension of the ASCII charset is 1).

> I find the comment about directly mapping very suspicious, when the
> charset contains a Lisp_Object, possibly requiring relocation. But it
> could well be that I misundertand something here.

First, before Stefan's changes there was no Lisp objects in 'struct
charset'.

And second, what do you mean by "possibly requiring relocation"?  Do
you mean relocation after restoring from dump, or do you mean
relocation during dumping?  Or something else entirely?