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
Reported by: Jan Synacek <jsynacek <at> redhat.com>
Date: Tue, 20 Mar 2018 10:26:01 UTC
Severity: important
Tags: fixed
Merged with 30045,
31547,
31758,
31801,
31936
Found in versions 26.1, 27.0.50, 25.3
Fixed in version 26.2
Done: Robert Pluim <rpluim <at> gmail.com>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: 30874 <at> debbugs.gnu.org, jsynacek <at> redhat.com
> Date: Tue, 27 Mar 2018 00:16:37 +0200
>
> I added some debug to libXft. When the set-fonset-font is executed,
> Xft loads /usr/share/fonts/eosrei-emojione/emojione-android.ttf. Some
> of the glyphs in that font cause Xft to allocate 16384 bytes of bitmap
> buffer, which is what causes the problems [1]. If I move that font out
> of the way I get no crash. I think we're back to a
> variant of Bug #30045.
Thanks!
Jan, do you also see this font loaded in your case?
So how do we end up loading that problematic font, and why does that
happen with the recipe for this bug, but not if set-fonset-font on the
command line is omitted?
It looks like this is a problem with all color emoji fonts, so this is
indeed a duplicate of bug#30045. See this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1498269
The question now becomes: how do we avoid loading such fonts, at least
when the xftfont back-end is in use? Is there any alternative except
telling users to "move such fonts out of the way"?
This bug report was last modified 6 years and 164 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.