GNU bug report logs - #30874
Displaying char \x274C with Dejavu Sans Mono gives "X protocol error: BadLength (poly request too large or internal Xlib length error) on protocol request 138"

Previous Next

Full log

View this message in rfc822 format

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 30874 <at> debbugs.gnu.org, jsynacek <at> redhat.com
Subject: bug#30874: 27.0.50; Emacs crashes
Date: Fri, 30 Mar 2018 15:00:43 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Robert Pluim <rpluim <at> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.