bug#30874: 27.0.50; Emacs crashes

[Robert Pluim <rpluim@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Until someone fixes
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20890>, Cairo is
>> basically unusable for me even without the redisplay issues.
>
> That part of cleanup_vector is under suspicion since it was born, see
> "git -L" reports about that function.  Perhaps the easiest band-aid
> (or maybe it's a real fix) would be to disable this part:
>
>   if (PSEUDOVECTOR_TYPEP (&vector->header, PVEC_FONT)
>       && ((vector->header.size & PSEUDOVECTOR_SIZE_MASK)
> 	  == FONT_OBJECT_MAX))
>     {
>       struct font_driver const *drv = ((struct font *) vector)->driver;
>
>       /* The font driver might sometimes be NULL, e.g. if Emacs was
> 	 interrupted before it had time to set it up.  */
>       if (drv)
> 	{
> 	  /* Attempt to catch subtle bugs like Bug#16140.  */
> 	  eassert (valid_font_driver (drv));
> 	  drv->close ((struct font *) vector);
> 	}
>     }
>
> when the font backend is one of those which use ftfont_close.  Or
> maybe just make ftfont_close return without doing anything if it is
> called from GC.

Iʼll look into that. I assume thereʼs an 'in_gc' variable we can check.

>> > AFAIK, there's no "fallback" per se.  Whenever the already-loaded
>> > fonts don't support a character, Emacs looks for the fonts that do
>> > using the "match" method.  If we always fail these fonts in that
>> > method, they will never be used.
>> 
>> Yes, I was confused about what was happening. This explains why I was
>> not getting Symbola as well: that font doesnʼt have a glyph for #x274c
>
> Symbola I have installed here does have a glyph for that character,
> FWIW.

Now Iʼm thoroughly confused as to what's happening. Eg LibreOffice
quite happily uses Symbola, so it has the glyph, but I see Emacs
skipping past Symbola until it arrives at VL Gothic. Itʼs not a big
deal though, I doubt itʼs a bug.

>> modified   src/ftfont.c
>> @@ -764,6 +764,8 @@ ftfont_spec_pattern (Lisp_Object spec, char *otlayout, struct OpenTypeSpec **ots
>>    if (scalable >= 0
>>        && ! FcPatternAddBool (pattern, FC_SCALABLE, scalable ? FcTrue : FcFalse))
>>      goto err;
>> +  /* We really don't like color fonts, they cause Xft crashes.  */
>> +  FcPatternAddBool(pattern, FC_COLOR, FcFalse);
>>  
>>    goto finish;
>
> Thanks!
>
> Jan, can you see if this patch fixes the problem for you?
>
> If Jan says it does fix the problem, I think we should install this on
> master.  What do you think about having this conditioned on a variable
> exposed to Lisp, as a "fire escape" in case there are some situations
> where users might want these fonts anyway?

I thought Xft had no real support for displaying these fonts anyway?

> Also, we should probably condition this by HAVE_XFT, since AFAIU the
> problem is only relevant to that build?

I think thatʼs right. At least the cairo build doesnʼt crash with the
reproduction recipe.

Robert