bug#30874: 27.0.50; Emacs crashes

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  30874@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@entry=0x2c5ba00, 
> rep=rep@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@entry=0x2c5ba00, 
> rep=rep@entry=0x7fffffff3330, extra=extra@entry=0, discard=discard@entry=1) 
> at xcb_io.c:621
> #15 0x00007ffff469970d in XSync (dpy=0x2c5ba00, discard=discard@entry=0) at 
> Sync.c:44
> #16 0x00007ffff46997ab in _XSyncFunction (dpy=<optimized out>) at Synchro.c:35
> #17 0x00007ffff4028fe1 in XRenderAddGlyphs (dpy=dpy@entry=0x2c5ba00, 
> glyphset=<optimized out>, gids=gids@entry=0x7fffffff34a8, 
> glyphs=glyphs@entry=0x3334840, nglyphs=nglyphs@entry=1, 
> images=images@entry=0x34e39b0 "", nbyte_images=<optimized out>) at Glyph.c:112
> #18 0x00007ffff3e1c7ef in XftFontLoadGlyphs (dpy=dpy@entry=0x2c5ba00, 
> pub=pub@entry=0x34dd100, need_bitmaps=need_bitmaps@entry=0, glyphs=<optimized 
> out>, glyphs@entry=0x7fffffff4540, nglyph=<optimized out>) at xftglyphs.c:694
> #19 0x00007ffff3e1943b in XftGlyphExtents (dpy=dpy@entry=0x2c5ba00, 
> pub=pub@entry=0x34dd100, glyphs=glyphs@entry=0x7fffffff49a0, 
> nglyphs=nglyphs@entry=94, extents=extents@entry=0x7fffffff5a34) at 
> xftextent.c:53
> #20 0x00007ffff3e195ca in XftTextExtents8 (dpy=dpy@entry=0x2c5ba00, 
> pub=pub@entry=0x34dd100, string=string@entry=0x2c046e1 <ascii_printable+1> 
> "!\"#$%&'()*+,-./0123456789:;<=>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefghijklmnopqrstuvwxyz{|}~",
>  len=len@entry=94, extents=extents@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?