bug#30874: 27.0.50; Emacs crashes

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 30874@debbugs.gnu.org,  jsynacek@redhat.com
> Gmane-Reply-To-List: yes
> Date: Fri, 30 Mar 2018 12:36:45 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> As I understand it, we should use fontconfig for finding fonts,
> >> harfbuzz for doing the layout, and cairo to actually render the
> >> result
> >
> > Does harfbuzz require Cairo?  If it does, that's unfortunate, because
> > the Cairo rendering option currently has a few known and annoying
> > redisplay bugs, which no one seems to be willing/capable of fixing.
> 
> 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.

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

> > I thought there could be a way of detecting those "color bitmap fonts"
> > by examining their attributes in ftfont_match and/or
> > ftfont_spec_pattern.  Then we could return a failure indication for
> > them.
> 
> So the pattern returned from fontconfig doesnʼt indicate anything
> specific we could use, but itʼs possible to modify the pattern we use
> for requesting. The following patch against emacs-26 fixes the crash
> for me (Emacs ends up using "Noto Emoji"). Definitely not intended to
> be applied to emacs-26.
> 
> 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?

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