Re: MPS: face-cache

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

> But there's also FRAME_FONTSET, e.g. for w32:
>
>   #define FRAME_FONTSET(f) ((f)->output_data.w32->fontset)
>
> Are we handling it correctly vis-a-vis GC?  fix_frame doesn't do
> anything with it, AFAICT.  Should it?
>

Yeah, I think I see something similar here, but I don't understand it.

In my case, it looks like a string which is created by Ffont_xlfd_name
is later garbled. The string is used as the name of a fontset. Fontsets
are PVEC_CHAR_TABLE, which, AFAIU, are treated like normal vectors
during old GC. It's a bit confusing to me... Fix_char_table does that
for the new GC in a similar way.

All the fontsets are held in an array Vfontset_table which is
staticpro'd. An index in that array is the "fontset id" which is passed
around. At least that's my understanding - that we mainly pass these
integer ids around.

On NS for example, I believe it's ns_output that contains a fontset id.

So, in summary, I don't understand how a fontset, i.e. the char
table/vector would not be traces - the staticpro'd array should make
that sure.

> Note that the string length in parse_str_as_multibyte is completely
> bogus, which led me look into what we do with fontsets, because frame
> #4 calls fontset_font.  The default fontset, Vdefault_fontset, is
> staticpro'd, but that's all I found.

Yeah, same here. String is garbage at some point, fontsets are somehow
involved, etc.