[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#30874: 27.0.50; Emacs crashes
From: |
Eli Zaretskii |
Subject: |
bug#30874: 27.0.50; Emacs crashes |
Date: |
Fri, 30 Mar 2018 14:46:31 +0300 |
> 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?
- bug#30874: 27.0.50; Emacs crashes, (continued)
- bug#30874: 27.0.50; Emacs crashes, Robert Pluim, 2018/03/26
- bug#30874: 27.0.50; Emacs crashes, Robert Pluim, 2018/03/26
- bug#30874: 27.0.50; Emacs crashes, Eli Zaretskii, 2018/03/26
- bug#30874: 27.0.50; Emacs crashes, Robert Pluim, 2018/03/27
- bug#30874: 27.0.50; Emacs crashes, Eli Zaretskii, 2018/03/29
- bug#30874: 27.0.50; Emacs crashes, Robert Pluim, 2018/03/29
- bug#30874: 27.0.50; Emacs crashes, Eli Zaretskii, 2018/03/29
- bug#30874: 27.0.50; Emacs crashes, Glenn Morris, 2018/03/30
- bug#30874: 27.0.50; Emacs crashes, Eli Zaretskii, 2018/03/30
- bug#30874: 27.0.50; Emacs crashes, Robert Pluim, 2018/03/30
- bug#30874: 27.0.50; Emacs crashes,
Eli Zaretskii <=
- bug#30874: 27.0.50; Emacs crashes, Robert Pluim, 2018/03/30
- bug#30874: 27.0.50; Emacs crashes, Eli Zaretskii, 2018/03/30
- bug#30874: 27.0.50; Emacs crashes, Robert Pluim, 2018/03/31
- bug#30874: 27.0.50; Emacs crashes, Eli Zaretskii, 2018/03/31
- bug#30874: 27.0.50; Emacs crashes, Jan Synacek, 2018/03/29