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: Mon, 26 Mar 2018 18:52:17 +0200
>
> > But now that I actually see it, I don't think I understand the reason:
> > the call to XftTextExtents8 asks the xft font back-end to produce the
> > extents for an all-ASCII string, so the fact that it may not have
> > glyphs for some exotic non-ASCII characters couldn't be the culprit.
>
> OK. Is it possible that because we're in synchronous mode that the
> signal has been received just at an inopportune moment?
I doubt that: the backtrace looks very much like describing the actual
call into the X libraries.
> It doesn't crash if I do eg (insert-char ?a), nor (insert-char #x700).
As expected. But if you put a breakpoint at line 378 of xftfont.c, do
you see the same call to XftTextExtents8 with the same arguments in
the case of 'a'?
> > Can you figure out what's going on here, and why?
>
> Looks like I'll have to go poking around in the guts of Xft. Pointers
> appreciated.
Sorry, I don't know enough about the xftfont back-end to provide any
pointers. Maybe someone else here would.
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.