bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#30874: 27.0.50; Emacs crashes


From: Eli Zaretskii
Subject: bug#30874: 27.0.50; Emacs crashes
Date: Mon, 26 Mar 2018 18:25:39 +0300

> From: Robert Pluim <address@hidden>
> Cc: Eli Zaretskii <address@hidden>,  address@hidden
> 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 (address@hidden, address@hidden) 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 (address@hidden, address@hidden, 
> address@hidden, address@hidden) at xcb_io.c:621
> #15 0x00007ffff469970d in XSync (dpy=0x2c5ba00, address@hidden) at Sync.c:44
> #16 0x00007ffff46997ab in _XSyncFunction (dpy=<optimized out>) at Synchro.c:35
> #17 0x00007ffff4028fe1 in XRenderAddGlyphs (address@hidden, 
> glyphset=<optimized out>, address@hidden, address@hidden, address@hidden, 
> address@hidden "", nbyte_images=<optimized out>) at Glyph.c:112
> #18 0x00007ffff3e1c7ef in XftFontLoadGlyphs (address@hidden, address@hidden, 
> address@hidden, glyphs=<optimized out>, address@hidden, nglyph=<optimized 
> out>) at xftglyphs.c:694
> #19 0x00007ffff3e1943b in XftGlyphExtents (address@hidden, address@hidden, 
> address@hidden, address@hidden, address@hidden) at xftextent.c:53
> #20 0x00007ffff3e195ca in XftTextExtents8 (address@hidden, address@hidden, 
> address@hidden <ascii_printable+1> 
> "!\"#$%&'()*+,-./0123456789:;<=>address@hidden|}~", address@hidden, 
> address@hidden) 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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]