[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#30874: 27.0.50; Emacs crashes
From: |
Robert Pluim |
Subject: |
bug#30874: 27.0.50; Emacs crashes |
Date: |
Fri, 30 Mar 2018 15:00:43 +0200 |
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
- 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, 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, 2018/03/30
- bug#30874: 27.0.50; Emacs crashes,
Robert Pluim <=
- 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