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: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 30874 <at> debbugs.gnu.org, jsynacek <at> redhat.com
Subject: bug#30874: 27.0.50; Emacs crashes
Date: Mon, 26 Mar 2018 18:25:39 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  30874 <at> debbugs.gnu.org
> Gmane-Reply-To-List: yes
> Date: Mon, 26 Mar 2018 12:33:50 +0200
> 
> FWIW, I can reproduce this on Fedora 27 with xterm.c patched to force
> synchronous operation. There's no crash, but Emacs hangs, so I sent it
> a SIGHUP and got the following:
> [...]
> #10 0x00000000004c316b in x_error_handler (display=0x2c5ba00, event=0x7fffffff3180) at xterm.c:9889
> #11 0x00007ffff469fe3a in _XError (dpy=dpy <at> entry=0x2c5ba00, rep=rep <at> entry=0x33f8e70) at XlibInt.c:1434
> #12 0x00007ffff469cd6b in handle_error (dpy=0x2c5ba00, err=0x33f8e70, in_XReply=<optimized out>) at xcb_io.c:199
> #13 0x00007ffff469ce15 in handle_response (dpy=0x2c5ba00, response=0x33f8e70, in_XReply=<optimized out>)
>     at xcb_io.c:311
> #14 0x00007ffff469dd70 in _XReply (dpy=dpy <at> entry=0x2c5ba00, rep=rep <at> entry=0x7fffffff3330, extra=extra <at> entry=0, discard=discard <at> entry=1) at xcb_io.c:621
> #15 0x00007ffff469970d in XSync (dpy=0x2c5ba00, discard=discard <at> entry=0) at Sync.c:44
> #16 0x00007ffff46997ab in _XSyncFunction (dpy=<optimized out>) at Synchro.c:35
> #17 0x00007ffff4028fe1 in XRenderAddGlyphs (dpy=dpy <at> entry=0x2c5ba00, glyphset=<optimized out>, gids=gids <at> entry=0x7fffffff34a8, glyphs=glyphs <at> entry=0x3334840, nglyphs=nglyphs <at> entry=1, images=images <at> entry=0x34e39b0 "", nbyte_images=<optimized out>) at Glyph.c:112
> #18 0x00007ffff3e1c7ef in XftFontLoadGlyphs (dpy=dpy <at> entry=0x2c5ba00, pub=pub <at> entry=0x34dd100, need_bitmaps=need_bitmaps <at> entry=0, glyphs=<optimized out>, glyphs <at> entry=0x7fffffff4540, nglyph=<optimized out>) at xftglyphs.c:694
> #19 0x00007ffff3e1943b in XftGlyphExtents (dpy=dpy <at> entry=0x2c5ba00, pub=pub <at> entry=0x34dd100, glyphs=glyphs <at> entry=0x7fffffff49a0, nglyphs=nglyphs <at> entry=94, extents=extents <at> entry=0x7fffffff5a34) at xftextent.c:53
> #20 0x00007ffff3e195ca in XftTextExtents8 (dpy=dpy <at> entry=0x2c5ba00, pub=pub <at> entry=0x34dd100, string=string <at> entry=0x2c046e1 <ascii_printable+1> "!\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~", len=len <at> entry=94, extents=extents <at> entry=0x7fffffff5a34) at xftextent.c:139
> #21 0x00000000005c9247 in xftfont_open (f=0x13f2c30 <bss_sbrk_buffer+8316432>, entity=XIL(0x1459ea5), pixel_size=27)
>     at xftfont.c:378

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.

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.

Can you figure out what's going on here, and why?

Previous Next

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