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

Package: emacs;

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>
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: Mon, 26 Mar 2018 18:52:17 +0200
Eli Zaretskii <eliz <at> gnu.org> writes:

>
> Thanks, this is what I suspected.
>
> 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'll rerun the
test and let it sit for a longer time to see if it changes anything.

> Also, if you replace #x274c in the original recipe with an ASCII
> codepoint, it doesn't crash, does it?  Yet I'd expect to see exactly
> the same call to XftTextExtents8 in xftfont_open in that case.

It doesn't crash if I do eg (insert-char ?a), nor (insert-char #x700).

> 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.

Robert




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.