bug#30874: 27.0.50; Emacs crashes

bug#30874: 27.0.50; Emacs crashes

[Jan Synacek]

Emacs crashes after executing the following on the current master
(commit b39ca55e294d3be3e4c6e142975256d7f8cdfe76):

emacs -Q --eval="(switch-to-buffer \"*scratch*\")" --eval="(insert-char #x274c)" --eval="(set-fontset-font \"fontset-default\" 'unicode \"Dejavu Sans Mono\")"



In GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
 of 2018-03-20 built on jsynacek-ntb.brq.redhat.com
Repository revision: b39ca55e294d3be3e4c6e142975256d7f8cdfe76
Windowing system distributor 'Fedora Project', version 11.0.11906000
System Description: Fedora 27 (Workstation Edition)

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
s-x is undefined
delete-backward-char: Text is read-only

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS NOTIFY
ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 THREADS LCMS2

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  show-paren-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
format-spec rfc822 mml mml-sec epa derived epg gnus-util rmail
rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils elec-pair finder-inf package easymenu
epg-config url-handlers url-parse auth-source cl-seq eieio eieio-core
cl-macs eieio-loaddefs password-cache json map url-vars seq byte-opt gv
bytecomp byte-compile cconv cl-loaddefs cl-lib time-date paren mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode
lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty
make-network-process emacs)

Memory information:
((conses 16 105982 7168)
 (symbols 48 21563 1)
 (miscs 40 55 107)
 (strings 32 32124 1542)
 (string-bytes 1 857535)
 (vectors 16 17159)
 (vector-slots 8 524353 8330)
 (floats 8 54 63)
 (intervals 56 201 0)
 (buffers 992 11))

bug#30874: 27.0.50; Emacs crashes

[Eli Zaretskii]

> From: Jan Synacek <jsynacek@redhat.com>
> Date: Tue, 20 Mar 2018 11:24:51 +0100
> 
> 
> Emacs crashes after executing the following on the current master
> (commit b39ca55e294d3be3e4c6e142975256d7f8cdfe76):
> 
> emacs -Q --eval="(switch-to-buffer \"*scratch*\")" --eval="(insert-char #x274c)" --eval="(set-fontset-font \"fontset-default\" 'unicode \"Dejavu Sans Mono\")"

Please show a C-level backtrace from the crash.

Thanks.

bug#30874: 27.0.50; Emacs crashes

[Jan Synacek]

On Tue, Mar 20, 2018 at 1:04 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Jan Synacek <jsynacek@redhat.com>
>> Date: Tue, 20 Mar 2018 11:24:51 +0100
>>
>>
>> Emacs crashes after executing the following on the current master
>> (commit b39ca55e294d3be3e4c6e142975256d7f8cdfe76):
>>
>> emacs -Q --eval="(switch-to-buffer \"*scratch*\")" --eval="(insert-char #x274c)" --eval="(set-fontset-font \"fontset-default\" 'unicode \"Dejavu Sans Mono\")"
>
> Please show a C-level backtrace from the crash.

Since the reproducer is so trivial, I didn't consider it important,
but there you go (just basic backtrace, the full one is hilariously
huge):

Thread 4 (Thread 0x7fffd9d3d700 (LWP 25228)):
#0  0x00007fffefb0a3db in poll () at /lib64/libc.so.6
#1  0x00007ffff4e03e99 in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#2  0x00007ffff4e03fac in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007fffd9d4542d in dconf_gdbus_worker_thread () at
/usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007ffff4e2b486 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007ffff047761b in start_thread () at /lib64/libpthread.so.0
#6  0x00007fffefb1698f in clone () at /lib64/libc.so.6

Thread 3 (Thread 0x7fffdbdfc700 (LWP 25227)):
#0  0x00007fffefb0a3db in poll () at /lib64/libc.so.6
#1  0x00007ffff4e03e99 in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#2  0x00007ffff4e04232 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007ffff53ecb56 in gdbus_shared_thread_func () at /lib64/libgio-2.0.so.0
#4  0x00007ffff4e2b486 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007ffff047761b in start_thread () at /lib64/libpthread.so.0
#6  0x00007fffefb1698f in clone () at /lib64/libc.so.6

Thread 2 (Thread 0x7fffe0e08700 (LWP 25226)):
#0  0x00007fffefb0a3db in poll () at /lib64/libc.so.6
#1  0x00007ffff4e03e99 in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#2  0x00007ffff4e03fac in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007ffff4e03ff1 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4  0x00007ffff4e2b486 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007ffff047761b in start_thread () at /lib64/libpthread.so.0
#6  0x00007fffefb1698f in clone () at /lib64/libc.so.6

Thread 1 (Thread 0x7ffff7fa2fc0 (LWP 25222)):
#0  0x00007ffff048298b in raise () at /lib64/libpthread.so.0
#1  0x00000000004f0571 in terminate_due_to_signal (sig=sig@entry=6,
backtrace_limit=backtrace_limit@entry=40) at emacs.c:395
#2  0x00000000005096a3 in emacs_abort () at sysdep.c:2426
#3  0x00000000004bf4c6 in x_connection_closed
(dpy=dpy@entry=0x2c59000, error_message=<optimized out>,
    error_message@entry=0x7fffffff45b0 "X protocol error: BadLength
(poly request too large or internal Xlib length error) on protocol
request 138", ioerror=ioerror@entry=false) at xterm.c:9831
#4  0x00000000004c2f50 in x_error_quitter (display=0x2c59000,
event=<optimized out>, event=<optimized out>) at xterm.c:9919
#5  0x00000000004c2fcb in x_error_handler (display=0x2c59000,
event=0x7fffffff4770) at xterm.c:9889
#6  0x00007ffff469ce3a in _XError () at /lib64/libX11.so.6
#7  0x00007ffff4699d6b in handle_error () at /lib64/libX11.so.6
#8  0x00007ffff4699e15 in handle_response () at /lib64/libX11.so.6
#9  0x00007ffff469a745 in _XEventsQueued () at /lib64/libX11.so.6
#10 0x00007ffff467bcca in XFlush () at /lib64/libX11.so.6
#11 0x00007ffff46b965e in _XimProtoDestroyIC () at /lib64/libX11.so.6
#12 0x00007ffff46a7a02 in XDestroyIC () at /lib64/libX11.so.6
#13 0x00000000004d408f in free_frame_xic (f=f@entry=0x13f0c30
<bss_sbrk_buffer+8312368>) at xfns.c:2676
#14 0x00000000004cc648 in x_free_frame_resources (f=0x13f0c30
<bss_sbrk_buffer+8312368>) at xterm.c:11777
#15 0x00000000004ccd1b in x_destroy_window (f=<optimized out>) at xterm.c:11906
#16 0x00000000004280d0 in delete_frame (frame=<optimized out>,
force=force@entry=0x98a0) at frame.c:2055
#17 0x00000000004bf543 in x_connection_closed
(dpy=dpy@entry=0x2c59000, error_message=<optimized out>,
    error_message@entry=0x7fffffff5b80 "X protocol error: BadLength
(poly request too large or internal Xlib length error) on protocol
request 138", ioerror=ioerror@entry=false) at xterm.c:9810
#18 0x00000000004c2f50 in x_error_quitter (display=0x2c59000,
event=<optimized out>, event=<optimized out>) at xterm.c:9919
#19 0x00000000004c2fcb in x_error_handler (display=0x2c59000,
event=0x7fffffff5d40) at xterm.c:9889
#20 0x00007ffff469ce3a in _XError () at /lib64/libX11.so.6
#21 0x00007ffff4699d6b in handle_error () at /lib64/libX11.so.6
---Type <return> to continue, or q <return> to quit---
#22 0x00007ffff4699e15 in handle_response () at /lib64/libX11.so.6
#23 0x00007ffff469a745 in _XEventsQueued () at /lib64/libX11.so.6
#24 0x00007ffff468c2bd in XPending () at /lib64/libX11.so.6
#25 0x00007ffff64f2c2e in gdk_event_source_prepare () at /lib64/libgdk-3.so.0
#26 0x00007ffff4e033f9 in g_main_context_prepare () at /lib64/libglib-2.0.so.0
#27 0x00007ffff4e03dcb in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#28 0x00007ffff4e03f57 in g_main_context_pending () at /lib64/libglib-2.0.so.0
#29 0x00007ffff69b2d1d in gtk_events_pending () at /lib64/libgtk-3.so.0
#30 0x00000000004bfee7 in XTread_socket (terminal=<optimized out>,
hold_quit=0x7fffffff6040) at xterm.c:9146
#31 0x00000000004f7301 in gobble_input () at keyboard.c:6890
#32 0x00000000004f7925 in handle_async_input () at keyboard.c:7127
#33 0x00000000004f7925 in process_pending_signals () at keyboard.c:7141
#34 0x00000000005c8e5c in xftfont_open (f=0x13f0c30
<bss_sbrk_buffer+8312368>, entity=0x1243cb5 <bss_sbrk_buffer+6555317>,
pixel_size=15) at xftfont.c:391
#35 0x000000000057a91c in font_open_entity (f=0x13f0c30
<bss_sbrk_buffer+8312368>, entity=0x1243cb5 <bss_sbrk_buffer+6555317>,
pixel_size=15) at font.c:2903
#36 0x00000000005cb0a4 in fontset_find_font
(fontset=fontset@entry=0x142ac35 <bss_sbrk_buffer+8549941>,
c=c@entry=10060, face=face@entry=0x32a8610,
charset_id=charset_id@entry=-1, fallback=fallback@entry=true)
    at fontset.c:707
#37 0x00000000005cb8bb in fontset_font
(fontset=fontset@entry=0x142ac35 <bss_sbrk_buffer+8549941>,
c=c@entry=10060, face=face@entry=0x32a8610, id=-1) at fontset.c:788
#38 0x00000000005cbbbc in face_for_char (f=0x13f0c30
<bss_sbrk_buffer+8312368>, face=face@entry=0x32a8610, c=10060,
pos=<optimized out>, object=<optimized out>) at fontset.c:990
#39 0x00000000004474d9 in FACE_FOR_CHAR (object=<optimized out>,
pos=<optimized out>, character=<optimized out>, face=0x32a8610,
f=<optimized out>) at dispextern.h:1818
#40 0x00000000004474d9 in get_next_display_element
(it=it@entry=0x7fffffff8a90) at xdisp.c:7324
#41 0x000000000044e5f8 in display_line (it=it@entry=0x7fffffff8a90,
cursor_vpos=cursor_vpos@entry=0) at xdisp.c:21502
#42 0x00000000004536fd in try_window (window=window@entry=0x13f1c35
<bss_sbrk_buffer+8316469>, pos=..., flags=flags@entry=1) at
xdisp.c:17718
#43 0x0000000000466751 in redisplay_window (window=0x13f1c35
<bss_sbrk_buffer+8316469>,
just_this_one_p=just_this_one_p@entry=false) at xdisp.c:17165
#44 0x00000000004692eb in redisplay_window_0
(window=window@entry=0x13f1c35 <bss_sbrk_buffer+8316469>) at
xdisp.c:14922
#45 0x0000000000561e86 in internal_condition_case_1
(bfun=bfun@entry=0x4692c0 <redisplay_window_0>,
arg=arg@entry=0x13f1c35 <bss_sbrk_buffer+8316469>, handlers=<optimized
out>, hfun=hfun@entry=0x42f220 <redisplay_window_error>) at
eval.c:1356
#46 0x0000000000434315 in redisplay_windows (window=0x13f1c35
<bss_sbrk_buffer+8316469>) at xdisp.c:14902
#47 0x000000000045705d in redisplay_internal () at xdisp.c:14385
#48 0x0000000000458d55 in redisplay () at xdisp.c:13597
#49 0x00000000004fa4bb in read_char (commandflag=commandflag@entry=1,
map=map@entry=0x15484b3 <bss_sbrk_buffer+9719475>, prev_event=0x0,
used_mouse_menu=used_mouse_menu@entry=0x7fffffffdf8b,
end_time=end_time@entry=0x0) at keyboard.c:2486
#50 0x00000000004fcffb in read_key_sequence
(keybuf=keybuf@entry=0x7fffffffe060, prompt=prompt@entry=0x0,
dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at
keyboard.c:9137
#51 0x00000000004feaee in command_loop_1 () at keyboard.c:1370
#52 0x0000000000561dee in internal_condition_case
(bfun=bfun@entry=0x4fe900 <command_loop_1>,
handlers=handlers@entry=0x5280, hfun=hfun@entry=0x4f5b20 <cmd_error>)
at eval.c:1332
#53 0x00000000004f093c in command_loop_2 (ignore=ignore@entry=0x0) at
keyboard.c:1111
#54 0x0000000000561d5d in internal_catch (tag=tag@entry=0xc750,
func=func@entry=0x4f0920 <command_loop_2>, arg=arg@entry=0x0) at
eval.c:1097
#55 0x00000000004f08e4 in command_loop () at keyboard.c:1090
#56 0x00000000004f5743 in recursive_edit_1 () at keyboard.c:696
#57 0x00000000004f5a57 in Frecursive_edit () at keyboard.c:767
#58 0x000000000041a73f in main (argc=5, argv=0x7fffffffe3c8) at emacs.c:1724

-- 
Jan Synacek
Software Engineer, Red Hat

bug#30874: 27.0.50; Emacs crashes

[Eli Zaretskii]

> From: Jan Synacek <jsynacek@redhat.com>
> Date: Tue, 20 Mar 2018 13:12:53 +0100
> Cc: 30874@debbugs.gnu.org
> 
> > Please show a C-level backtrace from the crash.
> 
> Since the reproducer is so trivial, I didn't consider it important,

It is always important.  I couldn't reproduce this on my system.

> but there you go (just basic backtrace, the full one is hilariously
> huge):

Thanks.  Sounds like a duplicate of bug#30045.

Can you run this in X synchronous mode, so that we see which operation
triggers the original X error?  etc/DEBUG tells how to do that under
"If you encounter X protocol errors".

bug#30874: 27.0.50; Emacs crashes

[Jan Synacek]

On Tue, Mar 20, 2018 at 1:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Jan Synacek <jsynacek@redhat.com>
>> Date: Tue, 20 Mar 2018 13:12:53 +0100
>> Cc: 30874@debbugs.gnu.org
>>
>> > Please show a C-level backtrace from the crash.
>>
>> Since the reproducer is so trivial, I didn't consider it important,
>
> It is always important.  I couldn't reproduce this on my system.
>
>> but there you go (just basic backtrace, the full one is hilariously
>> huge):
>
> Thanks.  Sounds like a duplicate of bug#30045.
>
> Can you run this in X synchronous mode, so that we see which operation
> triggers the original X error?  etc/DEBUG tells how to do that under
> "If you encounter X protocol errors".

I tried the following but it doesn't work:

gdb --args ./src/emacs -Q --eval='(setq x-command-line-resources
"emacs.synchronous: true")' --eval="(switch-to-buffer \"*scratch*\")"
--eval="(insert-char #x274c)" --eval="(set-fontset-font
\"fontset-default\" 'unicode \"Dejavu Sans Mono\")"
--eval="(debug-on-entry 'Fdelete_frame)"

I forgot to mention that this issue is reproducible on the latest
Fedora 27 running gnome and gdm. And as far as I know, I'm not running
wayland.

-- 
Jan Synacek
Software Engineer, Red Hat

bug#30874: 27.0.50; Emacs crashes

[Eli Zaretskii]

> From: Jan Synacek <jsynacek@redhat.com>
> Date: Thu, 22 Mar 2018 13:28:56 +0100
> Cc: 30874@debbugs.gnu.org
> 
> > Can you run this in X synchronous mode, so that we see which operation
> > triggers the original X error?  etc/DEBUG tells how to do that under
> > "If you encounter X protocol errors".
> 
> I tried the following but it doesn't work:
> 
> gdb --args ./src/emacs -Q --eval='(setq x-command-line-resources
> "emacs.synchronous: true")' --eval="(switch-to-buffer \"*scratch*\")"
> --eval="(insert-char #x274c)" --eval="(set-fontset-font
> \"fontset-default\" 'unicode \"Dejavu Sans Mono\")"
> --eval="(debug-on-entry 'Fdelete_frame)"

What about adding the -xrm "emacs.synchronous: true" switch to the
Emacs invocation command -- does it also not work?

Thanks.

bug#30874: 27.0.50; Emacs crashes

[Jan Synacek]

On Thu, Mar 22, 2018 at 2:01 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Jan Synacek <jsynacek@redhat.com>
>> Date: Thu, 22 Mar 2018 13:28:56 +0100
>> Cc: 30874@debbugs.gnu.org
>>
>> > Can you run this in X synchronous mode, so that we see which operation
>> > triggers the original X error?  etc/DEBUG tells how to do that under
>> > "If you encounter X protocol errors".
>>
>> I tried the following but it doesn't work:
>>
>> gdb --args ./src/emacs -Q --eval='(setq x-command-line-resources
>> "emacs.synchronous: true")' --eval="(switch-to-buffer \"*scratch*\")"
>> --eval="(insert-char #x274c)" --eval="(set-fontset-font
>> \"fontset-default\" 'unicode \"Dejavu Sans Mono\")"
>> --eval="(debug-on-entry 'Fdelete_frame)"
>
> What about adding the -xrm "emacs.synchronous: true" switch to the
> Emacs invocation command -- does it also not work?

As far as I can tell, no. I still see the emacs frame remain open but
unresponsive and also see the same backtrace as before.

-- 
Jan Synacek
Software Engineer, Red Hat

bug#30874: 27.0.50; Emacs crashes

[Eli Zaretskii]

> From: Jan Synacek <jsynacek@redhat.com>
> Date: Thu, 22 Mar 2018 14:05:26 +0100
> Cc: 30874@debbugs.gnu.org
> 
> > What about adding the -xrm "emacs.synchronous: true" switch to the
> > Emacs invocation command -- does it also not work?
> 
> As far as I can tell, no. I still see the emacs frame remain open but
> unresponsive and also see the same backtrace as before.

Exactly the same backtrace?  The backtrace you posted:

  #19 0x00000000004c2fcb in x_error_handler (display=0x2c59000,
  event=0x7fffffff5d40) at xterm.c:9889
  #20 0x00007ffff469ce3a in _XError () at /lib64/libX11.so.6
  #21 0x00007ffff4699d6b in handle_error () at /lib64/libX11.so.6
  ---Type <return> to continue, or q <return> to quit---
  #22 0x00007ffff4699e15 in handle_response () at /lib64/libX11.so.6
  #23 0x00007ffff469a745 in _XEventsQueued () at /lib64/libX11.so.6
  #24 0x00007ffff468c2bd in XPending () at /lib64/libX11.so.6
  #25 0x00007ffff64f2c2e in gdk_event_source_prepare () at /lib64/libgdk-3.so.0
  #26 0x00007ffff4e033f9 in g_main_context_prepare () at /lib64/libglib-2.0.so.0
  #27 0x00007ffff4e03dcb in g_main_context_iterate.isra () at
  /lib64/libglib-2.0.so.0
  #28 0x00007ffff4e03f57 in g_main_context_pending () at /lib64/libglib-2.0.so.0
  #29 0x00007ffff69b2d1d in gtk_events_pending () at /lib64/libgtk-3.so.0
  #30 0x00000000004bfee7 in XTread_socket (terminal=<optimized out>,
  hold_quit=0x7fffffff6040) at xterm.c:9146
  #31 0x00000000004f7301 in gobble_input () at keyboard.c:6890
  #32 0x00000000004f7925 in handle_async_input () at keyboard.c:7127
  #33 0x00000000004f7925 in process_pending_signals () at keyboard.c:7141
  #34 0x00000000005c8e5c in xftfont_open (f=0x13f0c30
  <bss_sbrk_buffer+8312368>, entity=0x1243cb5 <bss_sbrk_buffer+6555317>,
  pixel_size=15) at xftfont.c:391

indicates that the X error message was read when Emacs unblocked input
in xftfont_open, and read pending input.  In synchronous X operation,
the call to x_error_handler should come from an X function, not from
process_pending_signals.  I hoped that seeing the X function that
caused the error will allow us to understand better what is causing
the problem.  If you still see exactly the same backtrace in
synchronous X operation, then I don't see any path forward, except
saying that telling Emacs Dejavu Sans Mono can cover the entire
Unicode range of characters is not recommended.  (But when I did that
with a couple of fonts here, Emacs didn't crash.)  It could be a
problem in the font backend you use, or it could be something else.

Thanks.

bug#30874: 27.0.50; Emacs crashes

[Jan Synacek]

On Thu, Mar 22, 2018 at 3:55 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Jan Synacek <jsynacek@redhat.com>
>> Date: Thu, 22 Mar 2018 14:05:26 +0100
>> Cc: 30874@debbugs.gnu.org
>>
>> > What about adding the -xrm "emacs.synchronous: true" switch to the
>> > Emacs invocation command -- does it also not work?
>>
>> As far as I can tell, no. I still see the emacs frame remain open but
>> unresponsive and also see the same backtrace as before.
>
> Exactly the same backtrace?  The backtrace you posted:
>
>   #19 0x00000000004c2fcb in x_error_handler (display=0x2c59000,
>   event=0x7fffffff5d40) at xterm.c:9889
>   #20 0x00007ffff469ce3a in _XError () at /lib64/libX11.so.6
>   #21 0x00007ffff4699d6b in handle_error () at /lib64/libX11.so.6
>   ---Type <return> to continue, or q <return> to quit---
>   #22 0x00007ffff4699e15 in handle_response () at /lib64/libX11.so.6
>   #23 0x00007ffff469a745 in _XEventsQueued () at /lib64/libX11.so.6
>   #24 0x00007ffff468c2bd in XPending () at /lib64/libX11.so.6
>   #25 0x00007ffff64f2c2e in gdk_event_source_prepare () at /lib64/libgdk-3.so.0
>   #26 0x00007ffff4e033f9 in g_main_context_prepare () at /lib64/libglib-2.0.so.0
>   #27 0x00007ffff4e03dcb in g_main_context_iterate.isra () at
>   /lib64/libglib-2.0.so.0
>   #28 0x00007ffff4e03f57 in g_main_context_pending () at /lib64/libglib-2.0.so.0
>   #29 0x00007ffff69b2d1d in gtk_events_pending () at /lib64/libgtk-3.so.0
>   #30 0x00000000004bfee7 in XTread_socket (terminal=<optimized out>,
>   hold_quit=0x7fffffff6040) at xterm.c:9146
>   #31 0x00000000004f7301 in gobble_input () at keyboard.c:6890
>   #32 0x00000000004f7925 in handle_async_input () at keyboard.c:7127
>   #33 0x00000000004f7925 in process_pending_signals () at keyboard.c:7141
>   #34 0x00000000005c8e5c in xftfont_open (f=0x13f0c30
>   <bss_sbrk_buffer+8312368>, entity=0x1243cb5 <bss_sbrk_buffer+6555317>,
>   pixel_size=15) at xftfont.c:391
>
> indicates that the X error message was read when Emacs unblocked input
> in xftfont_open, and read pending input.  In synchronous X operation,
> the call to x_error_handler should come from an X function, not from
> process_pending_signals.  I hoped that seeing the X function that
> caused the error will allow us to understand better what is causing
> the problem.  If you still see exactly the same backtrace in
> synchronous X operation, then I don't see any path forward, except
> saying that telling Emacs Dejavu Sans Mono can cover the entire
> Unicode range of characters is not recommended.  (But when I did that
> with a couple of fonts here, Emacs didn't crash.)  It could be a
> problem in the font backend you use, or it could be something else.

$ gdb --args ./src/emacs -Q -xrm "emacs.synchronous: true"
--eval="(switch-to-buffer \"*scratch*\")" --eval="(insert-char
#x274c)" --eval="(set-fontset-font \"fontset-default\" 'unicode
\"Dejavu Sans Mono\")"
...
Thread 4 (Thread 0x7fffd9d3e700 (LWP 5625)):
#0  0x00007fffefb24c6b in poll () at /lib64/libc.so.6
#1  0x00007ffff4e06e99 in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#2  0x00007ffff4e06fac in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007fffd9d4642d in dconf_gdbus_worker_thread () at
/usr/lib64/gio/modules/libdconfsettings.so
#4  0x00007ffff4e2e486 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007ffff048550b in start_thread () at /lib64/libpthread.so.0
#6  0x00007fffefb2f16f in clone () at /lib64/libc.so.6

Thread 3 (Thread 0x7fffdbdfc700 (LWP 5624)):
#0  0x00007fffefb24c6b in poll () at /lib64/libc.so.6
#1  0x00007ffff4e06e99 in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#2  0x00007ffff4e07232 in g_main_loop_run () at /lib64/libglib-2.0.so.0
#3  0x00007ffff53efb56 in gdbus_shared_thread_func () at /lib64/libgio-2.0.so.0
#4  0x00007ffff4e2e486 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007ffff048550b in start_thread () at /lib64/libpthread.so.0
#6  0x00007fffefb2f16f in clone () at /lib64/libc.so.6

Thread 2 (Thread 0x7fffe0e3a700 (LWP 5623)):
#0  0x00007fffefb24c6b in poll () at /lib64/libc.so.6
#1  0x00007ffff4e06e99 in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#2  0x00007ffff4e06fac in g_main_context_iteration () at /lib64/libglib-2.0.so.0
#3  0x00007ffff4e06ff1 in glib_worker_main () at /lib64/libglib-2.0.so.0
#4  0x00007ffff4e2e486 in g_thread_proxy () at /lib64/libglib-2.0.so.0
#5  0x00007ffff048550b in start_thread () at /lib64/libpthread.so.0
#6  0x00007fffefb2f16f in clone () at /lib64/libc.so.6

Thread 1 (Thread 0x7ffff7fa2fc0 (LWP 5619)):
#0  0x00007ffff0490050 in raise () at /lib64/libpthread.so.0
#1  0x00000000004f0571 in terminate_due_to_signal (sig=sig@entry=6,
backtrace_limit=backtrace_limit@entry=40) at emacs.c:395
#2  0x00000000005096a3 in emacs_abort () at sysdep.c:2426
#3  0x00000000004bf4c6 in x_connection_closed
(dpy=dpy@entry=0x2c59430, error_message=<optimized out>,
    error_message@entry=0x7fffffff4580 "X protocol error: BadLength
(poly request too large or internal Xlib length error) on protocol
request 138", ioerror=ioerror@entry=false) at xterm.c:9831
#4  0x00000000004c2f50 in x_error_quitter (display=0x2c59430,
event=<optimized out>, event=<optimized out>) at xterm.c:9919
#5  0x00000000004c2fcb in x_error_handler (display=0x2c59430,
event=0x7fffffff4740) at xterm.c:9889
#6  0x00007ffff469fe3a in _XError () at /lib64/libX11.so.6
#7  0x00007ffff469cd6b in handle_error () at /lib64/libX11.so.6
#8  0x00007ffff469ce15 in handle_response () at /lib64/libX11.so.6
#9  0x00007ffff469d745 in _XEventsQueued () at /lib64/libX11.so.6
#10 0x00007ffff467ecca in XFlush () at /lib64/libX11.so.6
#11 0x00007ffff46bc65e in _XimProtoDestroyIC () at /lib64/libX11.so.6
#12 0x00007ffff46aaa02 in XDestroyIC () at /lib64/libX11.so.6
#13 0x00000000004d408f in free_frame_xic (f=f@entry=0x13f0c30
<bss_sbrk_buffer+8312368>) at xfns.c:2676
#14 0x00000000004cc648 in x_free_frame_resources (f=0x13f0c30
<bss_sbrk_buffer+8312368>) at xterm.c:11777
#15 0x00000000004ccd1b in x_destroy_window (f=<optimized out>) at xterm.c:11906
#16 0x00000000004280d0 in delete_frame (frame=<optimized out>,
force=force@entry=0x98a0) at frame.c:2055
#17 0x00000000004bf543 in x_connection_closed
(dpy=dpy@entry=0x2c59430, error_message=<optimized out>,
    error_message@entry=0x7fffffff5b50 "X protocol error: BadLength
(poly request too large or internal Xlib length error) on protocol
request 138", ioerror=ioerror@entry=false) at xterm.c:9810
#18 0x00000000004c2f50 in x_error_quitter (display=0x2c59430,
event=<optimized out>, event=<optimized out>) at xterm.c:9919
#19 0x00000000004c2fcb in x_error_handler (display=0x2c59430,
event=0x7fffffff5d10) at xterm.c:9889
#20 0x00007ffff469fe3a in _XError () at /lib64/libX11.so.6
#21 0x00007ffff469cd6b in handle_error () at /lib64/libX11.so.6
#22 0x00007ffff469ce15 in handle_response () at /lib64/libX11.so.6
#23 0x00007ffff469d745 in _XEventsQueued () at /lib64/libX11.so.6
#24 0x00007ffff468f2bd in XPending () at /lib64/libX11.so.6
#25 0x00007ffff64f5c2e in gdk_event_source_prepare () at /lib64/libgdk-3.so.0
#26 0x00007ffff4e063f9 in g_main_context_prepare () at /lib64/libglib-2.0.so.0
#27 0x00007ffff4e06dcb in g_main_context_iterate.isra () at
/lib64/libglib-2.0.so.0
#28 0x00007ffff4e06f57 in g_main_context_pending () at /lib64/libglib-2.0.so.0
#29 0x00007ffff69b5d1d in gtk_events_pending () at /lib64/libgtk-3.so.0
#30 0x00000000004bfee7 in XTread_socket (terminal=<optimized out>,
hold_quit=0x7fffffff6010) at xterm.c:9146
#31 0x00000000004f7301 in gobble_input () at keyboard.c:6890
#32 0x00000000004f7925 in handle_async_input () at keyboard.c:7127
#33 0x00000000004f7925 in process_pending_signals () at keyboard.c:7141
#34 0x00000000005c8e5c in xftfont_open (f=0x13f0c30
<bss_sbrk_buffer+8312368>, entity=0x2fae835, pixel_size=15) at
xftfont.c:391
#35 0x000000000057a91c in font_open_entity (f=0x13f0c30
<bss_sbrk_buffer+8312368>, entity=0x2fae835, pixel_size=15) at
font.c:2903
#36 0x00000000005cb0a4 in fontset_find_font
(fontset=fontset@entry=0x142ac35 <bss_sbrk_buffer+8549941>,
c=c@entry=10060, face=face@entry=0x2e3e260,
charset_id=charset_id@entry=-1, fallback=fallback@entry=true) at
fontset.c:707
#37 0x00000000005cb8bb in fontset_font
(fontset=fontset@entry=0x142ac35 <bss_sbrk_buffer+8549941>,
c=c@entry=10060, face=face@entry=0x2e3e260, id=-1) at fontset.c:788
#38 0x00000000005cbbbc in face_for_char (f=0x13f0c30
<bss_sbrk_buffer+8312368>, face=face@entry=0x2e3e260, c=10060,
pos=<optimized out>, object=<optimized out>)
    at fontset.c:990
#39 0x00000000004474d9 in FACE_FOR_CHAR (object=<optimized out>,
pos=<optimized out>, character=<optimized out>, face=0x2e3e260,
f=<optimized out>) at dispextern.h:1818
#40 0x00000000004474d9 in get_next_display_element
(it=it@entry=0x7fffffff8a60) at xdisp.c:7324
#41 0x000000000044e5f8 in display_line (it=it@entry=0x7fffffff8a60,
cursor_vpos=cursor_vpos@entry=0) at xdisp.c:21502
#42 0x00000000004536fd in try_window (window=window@entry=0x13f1c35
<bss_sbrk_buffer+8316469>, pos=..., flags=flags@entry=1) at
xdisp.c:17718
#43 0x0000000000466751 in redisplay_window (window=0x13f1c35
<bss_sbrk_buffer+8316469>,
just_this_one_p=just_this_one_p@entry=false) at xdisp.c:17165
#44 0x00000000004692eb in redisplay_window_0
(window=window@entry=0x13f1c35 <bss_sbrk_buffer+8316469>) at
xdisp.c:14922
#45 0x0000000000561e86 in internal_condition_case_1
(bfun=bfun@entry=0x4692c0 <redisplay_window_0>,
arg=arg@entry=0x13f1c35 <bss_sbrk_buffer+8316469>, handlers=<optimized
out>, hfun=hfun@entry=0x42f220 <redisplay_window_error>) at
eval.c:1356
#46 0x0000000000434315 in redisplay_windows (window=0x13f1c35
<bss_sbrk_buffer+8316469>) at xdisp.c:14902
#47 0x000000000045705d in redisplay_internal () at xdisp.c:14385
#48 0x0000000000458d55 in redisplay () at xdisp.c:13597
#49 0x00000000004fa4bb in read_char (commandflag=commandflag@entry=1,
map=map@entry=0x1548573 <bss_sbrk_buffer+9719667>, prev_event=0x0,
used_mouse_menu=used_mouse_menu@entry=0x7fffffffdf5b,
end_time=end_time@entry=0x0) at keyboard.c:2486
#50 0x00000000004fcffb in read_key_sequence
(keybuf=keybuf@entry=0x7fffffffe030, prompt=prompt@entry=0x0,
dont_downcase_last=dont_downcase_last@entry=false,
can_return_switch_frame=can_return_switch_frame@entry=true,
fix_current_buffer=fix_current_buffer@entry=true,
prevent_redisplay=prevent_redisplay@entry=false, bufsize=30)
    at keyboard.c:9137
#51 0x00000000004feaee in command_loop_1 () at keyboard.c:1370
#52 0x0000000000561dee in internal_condition_case
(bfun=bfun@entry=0x4fe900 <command_loop_1>,
handlers=handlers@entry=0x5280, hfun=hfun@entry=0x4f5b20 <cmd_error>)
    at eval.c:1332
#53 0x00000000004f093c in command_loop_2 (ignore=ignore@entry=0x0) at
keyboard.c:1111
#54 0x0000000000561d5d in internal_catch (tag=tag@entry=0xc750,
func=func@entry=0x4f0920 <command_loop_2>, arg=arg@entry=0x0) at
eval.c:1097
#55 0x00000000004f08e4 in command_loop () at keyboard.c:1090
#56 0x00000000004f5743 in recursive_edit_1 () at keyboard.c:696
#57 0x00000000004f5a57 in Frecursive_edit () at keyboard.c:767
#58 0x000000000041a73f in main (argc=7, argv=0x7fffffffe398) at emacs.c:1724

Reproducible with Fedora 27 using gnome and gdm. AFAIK, I'm not even
running wayland. I also use nvidia drivers version 390.42 in case it
matters.

-- 
Jan Synacek
Software Engineer, Red Hat

bug#30874: 27.0.50; Emacs crashes

[Robert Pluim]

Jan Synacek <jsynacek@redhat.com> writes:

>>   #19 0x00000000004c2fcb in x_error_handler (display=0x2c59000,
>>   event=0x7fffffff5d40) at xterm.c:9889
>>   #20 0x00007ffff469ce3a in _XError () at /lib64/libX11.so.6
>>   #21 0x00007ffff4699d6b in handle_error () at /lib64/libX11.so.6
>>   ---Type <return> to continue, or q <return> to quit---
>>   #22 0x00007ffff4699e15 in handle_response () at /lib64/libX11.so.6
>>   #23 0x00007ffff469a745 in _XEventsQueued () at /lib64/libX11.so.6
>>   #24 0x00007ffff468c2bd in XPending () at /lib64/libX11.so.6
>>   #25 0x00007ffff64f2c2e in gdk_event_source_prepare () at /lib64/libgdk-3.so.0
>>   #26 0x00007ffff4e033f9 in g_main_context_prepare () at /lib64/libglib-2.0.so.0
>>   #27 0x00007ffff4e03dcb in g_main_context_iterate.isra () at
>>   /lib64/libglib-2.0.so.0
>>   #28 0x00007ffff4e03f57 in g_main_context_pending () at /lib64/libglib-2.0.so.0
>>   #29 0x00007ffff69b2d1d in gtk_events_pending () at /lib64/libgtk-3.so.0
>>   #30 0x00000000004bfee7 in XTread_socket (terminal=<optimized out>,
>>   hold_quit=0x7fffffff6040) at xterm.c:9146
>>   #31 0x00000000004f7301 in gobble_input () at keyboard.c:6890
>>   #32 0x00000000004f7925 in handle_async_input () at keyboard.c:7127
>>   #33 0x00000000004f7925 in process_pending_signals () at keyboard.c:7141
>>   #34 0x00000000005c8e5c in xftfont_open (f=0x13f0c30
>>   <bss_sbrk_buffer+8312368>, entity=0x1243cb5 <bss_sbrk_buffer+6555317>,
>>   pixel_size=15) at xftfont.c:391
>>
>> indicates that the X error message was read when Emacs unblocked input
>> in xftfont_open, and read pending input.  In synchronous X operation,
>> the call to x_error_handler should come from an X function, not from
>> process_pending_signals.  I hoped that seeing the X function that
>> caused the error will allow us to understand better what is causing
>> the problem.  If you still see exactly the same backtrace in
>> synchronous X operation, then I don't see any path forward, except
>> saying that telling Emacs Dejavu Sans Mono can cover the entire
>> Unicode range of characters is not recommended.  (But when I did that
>> with a couple of fonts here, Emacs didn't crash.)  It could be a
>> problem in the font backend you use, or it could be something else.

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:

#0  0x00007ffff048b82d in pthread_cond_wait@@GLIBC_2.3.2 () at /lib64/libpthread.so.0
#1  0x00007ffff469dd02 in _XReply (dpy=dpy@entry=0x2c5ba00, rep=rep@entry=0x7fffffff2d00, extra=extra@entry=0, discard=discard@entry=1) at xcb_io.c:590
#2  0x00007ffff469970d in XSync (dpy=0x2c5ba00, discard=discard@entry=0) at Sync.c:44
#3  0x00007ffff46997ab in _XSyncFunction (dpy=<optimized out>) at Synchro.c:35
#4  0x00007ffff3e17dc8 in XftDrawDestroy (draw=0x3404580) at xftdraw.c:279
#5  0x00000000005c82a9 in xftfont_end_for_frame (f=0x13f2c30 <bss_sbrk_buffer+8316432>) at xftfont.c:686
#6  0x00000000005781fb in font_update_drivers (f=f@entry=0x13f2c30 <bss_sbrk_buffer+8316432>, new_drivers=new_drivers@entry=XIL(0)) at font.c:3540
#7  0x0000000000428179 in delete_frame (frame=<optimized out>, force=force@entry=XIL(0x98a0)) at frame.c:2013
#8  0x00000000004bf6e3 in x_connection_closed (dpy=dpy@entry=0x2c5ba00, error_message=<optimized out>, 
    error_message@entry=0x7fffffff2fc0 "X protocol error: BadLength (poly request too large or internal Xlib length error) on protocol request 138", ioerror=ioerror@entry=false) at xterm.c:9810
#9  0x00000000004c30f0 in x_error_quitter (display=0x2c5ba00, event=<optimized out>, event=<optimized out>)
    at xterm.c:9919
#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
#22 0x000000000057a9bc in font_open_entity (f=0x13f2c30 <bss_sbrk_buffer+8316432>, entity=XIL(0x1459ea5), pixel_size=27) at font.c:2903
#23 0x00000000005cb134 in fontset_find_font (fontset=fontset@entry=XIL(0x1466c35), c=c@entry=10060, face=face@entry=0x2d4a720, charset_id=charset_id@entry=-1, fallback=fallback@entry=true) at fontset.c:707
#24 0x00000000005cb94b in fontset_font (fontset=fontset@entry=XIL(0x1466c35), c=c@entry=10060, face=face@entry=0x2d4a720, id=-1) at fontset.c:788
#25 0x00000000005cbc4c in face_for_char (f=0x13f2c30 <bss_sbrk_buffer+8316432>, face=face@entry=0x2d4a720, c=10060, pos=<optimized out>, object=<optimized out>) at fontset.c:990
#26 0x0000000000447639 in FACE_FOR_CHAR (object=<optimized out>, pos=<optimized out>, character=<optimized out>, face=0x2d4a720, f=<optimized out>) at dispextern.h:1818
#27 0x0000000000447639 in get_next_display_element (it=it@entry=0x7fffffff83c0) at xdisp.c:7324
#28 0x000000000044e758 in display_line (it=it@entry=0x7fffffff83c0, cursor_vpos=cursor_vpos@entry=5) at xdisp.c:21502
#29 0x000000000045389d in try_window (window=window@entry=XIL(0x13f3c35), pos=..., flags=flags@entry=1)
    at xdisp.c:17718
#30 0x00000000004668f1 in redisplay_window (window=XIL(0x13f3c35), just_this_one_p=just_this_one_p@entry=false)
    at xdisp.c:17165
#31 0x000000000046948b in redisplay_window_0 (window=window@entry=XIL(0x13f3c35)) at xdisp.c:14922
#32 0x0000000000561f46 in internal_condition_case_1 (bfun=bfun@entry=0x469460 <redisplay_window_0>, arg=arg@entry=XIL(0x13f3c35), handlers=<optimized out>, hfun=hfun@entry=0x42f380 <redisplay_window_error>) at eval.c:1356
#33 0x0000000000434475 in redisplay_windows (window=XIL(0x13f3c35)) at xdisp.c:14902
#34 0x00000000004571fd in redisplay_internal () at xdisp.c:14385
#35 0x0000000000458ef5 in redisplay () at xdisp.c:13597
#36 0x00000000004fa5bb in read_char (commandflag=commandflag@entry=1, map=map@entry=XIL(0x34aa213), prev_event=XIL(0), used_mouse_menu=used_mouse_menu@entry=0x7fffffffd8bb, end_time=end_time@entry=0x0) at keyboard.c:2486
#37 0x00000000004fd0fb in read_key_sequence (keybuf=keybuf@entry=0x7fffffffd990, prompt=prompt@entry=XIL(0), dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false, bufsize=30) at keyboard.c:9137
#38 0x00000000004febee in command_loop_1 () at keyboard.c:1370
#39 0x0000000000561eae in internal_condition_case (bfun=bfun@entry=0x4fea00 <command_loop_1>, handlers=handlers@entry=XIL(0x5280), hfun=hfun@entry=0x4f5c20 <cmd_error>) at eval.c:1332
#40 0x00000000004f0a3c in command_loop_2 (ignore=ignore@entry=XIL(0)) at keyboard.c:1111
#41 0x0000000000561e1d in internal_catch (tag=tag@entry=XIL(0xc750), func=func@entry=0x4f0a20 <command_loop_2>, arg=arg@entry=XIL(0)) at eval.c:1097
#42 0x00000000004f09e4 in command_loop () at keyboard.c:1090
#43 0x00000000004f5843 in recursive_edit_1 () at keyboard.c:696
#44 0x00000000004f5b57 in Frecursive_edit () at keyboard.c:767
#45 0x000000000041a840 in main (argc=2, argv=0x7fffffffdcf8) at emacs.c:1724

Robert

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?

bug#30874: 27.0.50; Emacs crashes

[Robert Pluim]

Eli Zaretskii <eliz@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

bug#30874: 27.0.50; Emacs crashes

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 30874@debbugs.gnu.org,  jsynacek@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.

bug#30874: 27.0.50; Emacs crashes

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: 30874@debbugs.gnu.org,  jsynacek@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.

Yes. Looks like Xft is stuck waiting on a futex somewhere.

>> 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'?

No, not for 'a'. I do see it for #x700. XftTextExtents8 does get
called a bunch of times during startup though.

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

You're in a maze of twisty pointers, all subtly different and
half-opaque. I may end up having to build my own Xft lib.

Robert

bug#30874: 27.0.50; Emacs crashes

[Robert Pluim]

Robert Pluim <rpluim@gmail.com> writes:

> You're in a maze of twisty pointers, all subtly different and
> half-opaque. I may end up having to build my own Xft lib.

Eli nailed it in about the 2nd message of this thread.

I added some debug to libXft. When the set-fonset-font is executed,
Xft loads /usr/share/fonts/eosrei-emojione/emojione-android.ttf. Some
of the glyphs in that font cause Xft to allocate 16384 bytes of bitmap
buffer, which is what causes the problems [1]. If I move that font out
of the way I get no crash. I think we're back to a
variant of Bug #30045.

Robert

Footnotes: 
[1]  Is Xft *really* this fragile?

bug#30874: 27.0.50; Emacs crashes

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 30874@debbugs.gnu.org,  jsynacek@redhat.com
> Date: Tue, 27 Mar 2018 00:16:37 +0200
> 
> I added some debug to libXft. When the set-fonset-font is executed,
> Xft loads /usr/share/fonts/eosrei-emojione/emojione-android.ttf. Some
> of the glyphs in that font cause Xft to allocate 16384 bytes of bitmap
> buffer, which is what causes the problems [1]. If I move that font out
> of the way I get no crash. I think we're back to a
> variant of Bug #30045.

Thanks!

Jan, do you also see this font loaded in your case?

So how do we end up loading that problematic font, and why does that
happen with the recipe for this bug, but not if set-fonset-font on the
command line is omitted?

It looks like this is a problem with all color emoji fonts, so this is
indeed a duplicate of bug#30045.  See this bug:

  https://bugzilla.redhat.com/show_bug.cgi?id=1498269

The question now becomes: how do we avoid loading such fonts, at least
when the xftfont back-end is in use?  Is there any alternative except
telling users to "move such fonts out of the way"?

bug#30874: 27.0.50; Emacs crashes

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

> So how do we end up loading that problematic font, and why does that
> happen with the recipe for this bug, but not if set-fonset-font on the
> command line is omitted?

Hereʼs what the file loading looks like from Xft's perspective:

XFT_DEBUG=16 LD_LIBRARY_PATH=/home/rpluim/repos/src/libXft-2.3.2/src/.libs/ ./emacs -Q

XFT_DEBUG=16
FontFile /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0 matches new
Loading file /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0
FontFile /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0 matches existing (2)
FontFile /usr/share/fonts/inconsolata/Inconsolata-Bold.ttf/0 matches new
Loading file /usr/share/fonts/inconsolata/Inconsolata-Bold.ttf/0

# Inconsolata is my system default monospace font. Now I insert #x274c :

FontFile /usr/share/fonts/inconsolata/Inconsolata-Regular.ttf/0 matches new
Loading file /usr/share/fonts/inconsolata/Inconsolata-Regular.ttf/0
FontFile /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf/0 matches new
Loading file /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf/0

# I think this means Inconsolata doesnʼt have a glyph for that
# codepoint, although I thought the default fontset specified Symbola
# for that codepoint (and Symbola is installed), so I donʼt understand
# why VL-Gothic is chosen.
# Now I change the fontset, and this time it finds the
# emojione-android font :
  
FontFile /usr/share/fonts/dejavu/DejaVuSansMono.ttf/0 matches new
Loading file /usr/share/fonts/dejavu/DejaVuSansMono.ttf/0
FontFile /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0 matches existing (2)
FontFile /usr/share/fonts/eosrei-emojione/emojione-android.ttf/0 matches new
Loading file /usr/share/fonts/eosrei-emojione/emojione-android.ttf/0

> It looks like this is a problem with all color emoji fonts, so this is
> indeed a duplicate of bug#30045.  See this bug:
>
>   https://bugzilla.redhat.com/show_bug.cgi?id=1498269
>
> The question now becomes: how do we avoid loading such fonts, at least
> when the xftfont back-end is in use?  Is there any alternative except
> telling users to "move such fonts out of the way"?

Accoding to that bug, the solution is for the application to 'move
away from legacy Xft to fontconfig', whatever that means. I can say
that building '--without-xft' is definitely sub-optimal (the buffer
text isnʼt scaled, and Emacs doesnʼt find a font to display #x274c).

Robert

bug#30874: 27.0.50; Emacs crashes

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 30874@debbugs.gnu.org,  jsynacek@redhat.com
> Date: Tue, 27 Mar 2018 10:57:03 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > So how do we end up loading that problematic font, and why does that
> > happen with the recipe for this bug, but not if set-fonset-font on the
> > command line is omitted?
> 
> Hereʼs what the file loading looks like from Xft's perspective:
> 
> XFT_DEBUG=16 LD_LIBRARY_PATH=/home/rpluim/repos/src/libXft-2.3.2/src/.libs/ ./emacs -Q
> 
> XFT_DEBUG=16
> FontFile /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0 matches new
> Loading file /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0
> FontFile /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0 matches existing (2)
> FontFile /usr/share/fonts/inconsolata/Inconsolata-Bold.ttf/0 matches new
> Loading file /usr/share/fonts/inconsolata/Inconsolata-Bold.ttf/0
> 
> # Inconsolata is my system default monospace font. Now I insert #x274c :
> 
> FontFile /usr/share/fonts/inconsolata/Inconsolata-Regular.ttf/0 matches new
> Loading file /usr/share/fonts/inconsolata/Inconsolata-Regular.ttf/0
> FontFile /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf/0 matches new
> Loading file /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf/0

What does "matches new" mean in this log?  And what does "matches
existing" (below) mean?

> # I think this means Inconsolata doesnʼt have a glyph for that
> # codepoint, although I thought the default fontset specified Symbola
> # for that codepoint (and Symbola is installed), so I donʼt understand
> # why VL-Gothic is chosen.

Strange indeed.  Does setting use-default-font-for-symbols to a nil
value change this in any way?

> # Now I change the fontset, and this time it finds the
> # emojione-android font :
>   
> FontFile /usr/share/fonts/dejavu/DejaVuSansMono.ttf/0 matches new
> Loading file /usr/share/fonts/dejavu/DejaVuSansMono.ttf/0
> FontFile /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0 matches existing (2)
> FontFile /usr/share/fonts/eosrei-emojione/emojione-android.ttf/0 matches new
> Loading file /usr/share/fonts/eosrei-emojione/emojione-android.ttf/0

Right.  Does use-default-font-for-symbols change anything in this
case?

> > It looks like this is a problem with all color emoji fonts, so this is
> > indeed a duplicate of bug#30045.  See this bug:
> >
> >   https://bugzilla.redhat.com/show_bug.cgi?id=1498269
> >
> > The question now becomes: how do we avoid loading such fonts, at least
> > when the xftfont back-end is in use?  Is there any alternative except
> > telling users to "move such fonts out of the way"?
> 
> Accoding to that bug, the solution is for the application to 'move
> away from legacy Xft to fontconfig', whatever that means. I can say
> that building '--without-xft' is definitely sub-optimal (the buffer
> text isnʼt scaled, and Emacs doesnʼt find a font to display #x274c).

We already use fontconfig to some extent, and xftfont is AFAIK the
most advanced font backend we have.  Patches for switching to using
more of fontconfig's features (assuming it can replace Xft), or for
switching to a more modern back-end (harfbuzz?) are welcome, but I
don't hold my breath, as I don't think we have expert on board who
know enough about complex script shaping to make progress in those
directions.

As a stopgap, I think we should find a way of ignoring the problematic
fonts.  Is there some way of detecting them?  AFAICT, we could do that
either in ftfont_match or in its subroutine ftfont_spec_pattern.  We
could then pretend that these fonts don't match any font spec, perhaps
subject to some variable (which would provide a 'fire escape"), which
I think would fix the problem.

Failing that, we could have a non-empty list in face-ignored-fonts,
but that would be an inferior solution, and it would take us more time
to come up with the full list of the problematic fonts.

Thanks.

bug#30874: 27.0.50; Emacs crashes

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> # Inconsolata is my system default monospace font. Now I insert #x274c :
>> 
>> FontFile /usr/share/fonts/inconsolata/Inconsolata-Regular.ttf/0 matches new
>> Loading file /usr/share/fonts/inconsolata/Inconsolata-Regular.ttf/0
>> FontFile /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf/0 matches new
>> Loading file /usr/share/fonts/vlgothic/VL-Gothic-Regular.ttf/0
>
> What does "matches new" mean in this log?  And what does "matches
> existing" (below) mean?

"matches new" means "this is the first time Xft has loaded this file",
similarly "matches existing" means "already loaded" (this is Xftʼs
debug, not mine)

>> # I think this means Inconsolata doesnʼt have a glyph for that
>> # codepoint, although I thought the default fontset specified Symbola
>> # for that codepoint (and Symbola is installed), so I donʼt understand
>> # why VL-Gothic is chosen.
>
> Strange indeed.  Does setting use-default-font-for-symbols to a nil
> value change this in any way?

No change. Iʼm beginning to suspect that when we query for the font
that Xft is doing font subsitution for us.

>> # Now I change the fontset, and this time it finds the
>> # emojione-android font :
>>   
>> FontFile /usr/share/fonts/dejavu/DejaVuSansMono.ttf/0 matches new
>> Loading file /usr/share/fonts/dejavu/DejaVuSansMono.ttf/0
>> FontFile /home/rpluim/.local/share/fonts/Inconsolata-Regular.ttf/0 matches existing (2)
>> FontFile /usr/share/fonts/eosrei-emojione/emojione-android.ttf/0 matches new
>> Loading file /usr/share/fonts/eosrei-emojione/emojione-android.ttf/0
>
> Right.  Does use-default-font-for-symbols change anything in this
> case?

No change

>> > The question now becomes: how do we avoid loading such fonts, at least
>> > when the xftfont back-end is in use?  Is there any alternative except
>> > telling users to "move such fonts out of the way"?
>> 
>> Accoding to that bug, the solution is for the application to 'move
>> away from legacy Xft to fontconfig', whatever that means. I can say
>> that building '--without-xft' is definitely sub-optimal (the buffer
>> text isnʼt scaled, and Emacs doesnʼt find a font to display #x274c).
>

Actually, I think this is because '--without-xft' also disables
Freetype, according to the configure log.

> We already use fontconfig to some extent, and xftfont is AFAIK the
> most advanced font backend we have.  Patches for switching to using
> more of fontconfig's features (assuming it can replace Xft), or for
> switching to a more modern back-end (harfbuzz?) are welcome, but I
> don't hold my breath, as I don't think we have expert on board who
> know enough about complex script shaping to make progress in those
> directions.

As I understand it, we should use fontconfig for finding fonts,
harfbuzz for doing the layout, and cairo to actually render the
result, but this is definitely not my area (plus itʼs Emacs redisplay,
which Iʼm told is scary)

I do note we have an Xft font backend, a freetype one, and a
freetype+cairo one already, which seems excessive.

> As a stopgap, I think we should find a way of ignoring the problematic
> fonts.  Is there some way of detecting them?

You mean short of running ftfont_get_bitmap over every available
codepoint in the font and skipping it if the resulting width * height
is > 4096 [1]?  That would probably detect a problematic font pretty
quickly, but is not very elegant. Also Iʼm not sure we get to
intervene before Xft decides that it needs to fall back to that font.

> AFAICT, we could do that
> either in ftfont_match or in its subroutine ftfont_spec_pattern.  We
> could then pretend that these fonts don't match any font spec, perhaps
> subject to some variable (which would provide a 'fire escape"), which
> I think would fix the problem.

Iʼm hoping that matching on something like !'family emoji' would work,
although Iʼve not figured out how to express that in fontconfig-speak.

> Failing that, we could have a non-empty list in face-ignored-fonts,
> but that would be an inferior solution, and it would take us more time
> to come up with the full list of the problematic fonts.

That works, but it also feels hacky.

Robert

Footnotes:
[1]  If only the calculation were that simple

bug#30874: 27.0.50; Emacs crashes

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 30874@debbugs.gnu.org,  jsynacek@redhat.com
> Date: Thu, 29 Mar 2018 18:14:11 +0200
> 
> > We already use fontconfig to some extent, and xftfont is AFAIK the
> > most advanced font backend we have.  Patches for switching to using
> > more of fontconfig's features (assuming it can replace Xft), or for
> > switching to a more modern back-end (harfbuzz?) are welcome, but I
> > don't hold my breath, as I don't think we have expert on board who
> > know enough about complex script shaping to make progress in those
> > directions.
> 
> As I understand it, we should use fontconfig for finding fonts,
> harfbuzz for doing the layout, and cairo to actually render the
> result

Does harfbuzz require Cairo?  If it does, that's unfortunate, because
the Cairo rendering option currently has a few known and annoying
redisplay bugs, which no one seems to be willing/capable of fixing.

> plus itʼs Emacs redisplay, which Iʼm told is scary

Don't believe the rumors too much.  Besides, adding a font backend
doesn't require to mess with the display code in any way, all you need
is implement the interfaces you see documented in 'struct font_driver'
defined in font.h (reusing the methods of existing backends where
appropriate, as xftfont does with ftfont methods); all the rest is
already taken care of in the infrastructure.  The only interface
between font back-end methods and the display engine is via 'struct
glyph_string', which is a relatvely simple data structure.

> I do note we have an Xft font backend, a freetype one, and a
> freetype+cairo one already, which seems excessive.

You forgot xfont and freetype-without-XFT.  It could be that we could
remove some of them, but I don't know which ones are used and how
much.  And freetype+cairo is not used much because of the Cairo
problems.

> > As a stopgap, I think we should find a way of ignoring the problematic
> > fonts.  Is there some way of detecting them?
> 
> You mean short of running ftfont_get_bitmap over every available
> codepoint in the font and skipping it if the resulting width * height
> is > 4096 [1]?  That would probably detect a problematic font pretty
> quickly, but is not very elegant. Also Iʼm not sure we get to
> intervene before Xft decides that it needs to fall back to that font.

AFAIK, there's no "fallback" per se.  Whenever the already-loaded
fonts don't support a character, Emacs looks for the fonts that do
using the "match" method.  If we always fail these fonts in that
method, they will never be used.

> > AFAICT, we could do that
> > either in ftfont_match or in its subroutine ftfont_spec_pattern.  We
> > could then pretend that these fonts don't match any font spec, perhaps
> > subject to some variable (which would provide a 'fire escape"), which
> > I think would fix the problem.
> 
> Iʼm hoping that matching on something like !'family emoji' would work,
> although Iʼve not figured out how to express that in fontconfig-speak.

I thought there could be a way of detecting those "color bitmap fonts"
by examining their attributes in ftfont_match and/or
ftfont_spec_pattern.  Then we could return a failure indication for
them.

bug#30874: 27.0.50; Emacs crashes

[Glenn Morris]

Eli Zaretskii wrote:

> Does harfbuzz require Cairo?  If it does, that's unfortunate, because
> the Cairo rendering option currently has a few known and annoying
> redisplay bugs, which no one seems to be willing/capable of fixing.

Jan mentioned this in the initial addition of cairo:

http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00795.html

   [...] it is just a step to keep up with the times, i.e. server side
   (as in X11 server) rendering is going away as it seems. So Emacs must
   at some point develop client side (cairo) rendering.

bug#30874: 27.0.50; Emacs crashes

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: Robert Pluim <rpluim@gmail.com>,  30874@debbugs.gnu.org,  jsynacek@redhat.com
> Date: Fri, 30 Mar 2018 01:10:27 -0400
> 
> Eli Zaretskii wrote:
> 
> > Does harfbuzz require Cairo?  If it does, that's unfortunate, because
> > the Cairo rendering option currently has a few known and annoying
> > redisplay bugs, which no one seems to be willing/capable of fixing.
> 
> Jan mentioned this in the initial addition of cairo:
> 
> http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00795.html
> 
>    [...] it is just a step to keep up with the times, i.e. server side
>    (as in X11 server) rendering is going away as it seems. So Emacs must
>    at some point develop client side (cairo) rendering.

Yes, we hoped Cairo will gradually take over the current defaults, but
its problems must be fixed before we can do that.

bug#30874: 27.0.50; Emacs crashes

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> As I understand it, we should use fontconfig for finding fonts,
>> harfbuzz for doing the layout, and cairo to actually render the
>> result
>
> Does harfbuzz require Cairo?  If it does, that's unfortunate, because
> the Cairo rendering option currently has a few known and annoying
> redisplay bugs, which no one seems to be willing/capable of fixing.

Until someone fixes
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20890>, Cairo is
basically unusable for me even without the redisplay issues.

>> plus itʼs Emacs redisplay, which Iʼm told is scary
>
> Don't believe the rumors too much.  Besides, adding a font backend
> doesn't require to mess with the display code in any way, all you need
> is implement the interfaces you see documented in 'struct font_driver'
> defined in font.h (reusing the methods of existing backends where
> appropriate, as xftfont does with ftfont methods); all the rest is
> already taken care of in the infrastructure.  The only interface
> between font back-end methods and the display engine is via 'struct
> glyph_string', which is a relatvely simple data structure.
>
>> I do note we have an Xft font backend, a freetype one, and a
>> freetype+cairo one already, which seems excessive.
>
> You forgot xfont and freetype-without-XFT.  It could be that we could
> remove some of them, but I don't know which ones are used and how
> much.  And freetype+cairo is not used much because of the Cairo
> problems.

I suspect Xft is the only one really used, since freetype-without-xft
is disabled if I read configure.ac right. Freetype + cairo is the one
we should probably target, as Xft used direct X calls which will stop
working once the world moves to Wayland.

>> > As a stopgap, I think we should find a way of ignoring the problematic
>> > fonts.  Is there some way of detecting them?
>> 
>> You mean short of running ftfont_get_bitmap over every available
>> codepoint in the font and skipping it if the resulting width * height
>> is > 4096 [1]?  That would probably detect a problematic font pretty
>> quickly, but is not very elegant. Also Iʼm not sure we get to
>> intervene before Xft decides that it needs to fall back to that font.
>
> AFAIK, there's no "fallback" per se.  Whenever the already-loaded
> fonts don't support a character, Emacs looks for the fonts that do
> using the "match" method.  If we always fail these fonts in that
> method, they will never be used.

Yes, I was confused about what was happening. This explains why I was
not getting Symbola as well: that font doesnʼt have a glyph for #x274c

>> > AFAICT, we could do that
>> > either in ftfont_match or in its subroutine ftfont_spec_pattern.  We
>> > could then pretend that these fonts don't match any font spec, perhaps
>> > subject to some variable (which would provide a 'fire escape"), which
>> > I think would fix the problem.
>> 
>> Iʼm hoping that matching on something like !'family emoji' would work,
>> although Iʼve not figured out how to express that in fontconfig-speak.
>
> I thought there could be a way of detecting those "color bitmap fonts"
> by examining their attributes in ftfont_match and/or
> ftfont_spec_pattern.  Then we could return a failure indication for
> them.

So the pattern returned from fontconfig doesnʼt indicate anything
specific we could use, but itʼs possible to modify the pattern we use
for requesting. The following patch against emacs-26 fixes the crash
for me (Emacs ends up using "Noto Emoji"). Definitely not intended to
be applied to emacs-26.

modified   src/ftfont.c
@@ -764,6 +764,8 @@ ftfont_spec_pattern (Lisp_Object spec, char *otlayout, struct OpenTypeSpec **ots
   if (scalable >= 0
       && ! FcPatternAddBool (pattern, FC_SCALABLE, scalable ? FcTrue : FcFalse))
     goto err;
+  /* We really don't like color fonts, they cause Xft crashes.  */
+  FcPatternAddBool(pattern, FC_COLOR, FcFalse);
 
   goto finish;
 

bug#30874: 27.0.50; Emacs crashes

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 30874@debbugs.gnu.org,  jsynacek@redhat.com
> Gmane-Reply-To-List: yes
> Date: Fri, 30 Mar 2018 12:36:45 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> As I understand it, we should use fontconfig for finding fonts,
> >> harfbuzz for doing the layout, and cairo to actually render the
> >> result
> >
> > Does harfbuzz require Cairo?  If it does, that's unfortunate, because
> > the Cairo rendering option currently has a few known and annoying
> > redisplay bugs, which no one seems to be willing/capable of fixing.
> 
> Until someone fixes
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20890>, Cairo is
> basically unusable for me even without the redisplay issues.

That part of cleanup_vector is under suspicion since it was born, see
"git -L" reports about that function.  Perhaps the easiest band-aid
(or maybe it's a real fix) would be to disable this part:

  if (PSEUDOVECTOR_TYPEP (&vector->header, PVEC_FONT)
      && ((vector->header.size & PSEUDOVECTOR_SIZE_MASK)
	  == FONT_OBJECT_MAX))
    {
      struct font_driver const *drv = ((struct font *) vector)->driver;

      /* The font driver might sometimes be NULL, e.g. if Emacs was
	 interrupted before it had time to set it up.  */
      if (drv)
	{
	  /* Attempt to catch subtle bugs like Bug#16140.  */
	  eassert (valid_font_driver (drv));
	  drv->close ((struct font *) vector);
	}
    }

when the font backend is one of those which use ftfont_close.  Or
maybe just make ftfont_close return without doing anything if it is
called from GC.

> > AFAIK, there's no "fallback" per se.  Whenever the already-loaded
> > fonts don't support a character, Emacs looks for the fonts that do
> > using the "match" method.  If we always fail these fonts in that
> > method, they will never be used.
> 
> Yes, I was confused about what was happening. This explains why I was
> not getting Symbola as well: that font doesnʼt have a glyph for #x274c

Symbola I have installed here does have a glyph for that character,
FWIW.

> > I thought there could be a way of detecting those "color bitmap fonts"
> > by examining their attributes in ftfont_match and/or
> > ftfont_spec_pattern.  Then we could return a failure indication for
> > them.
> 
> So the pattern returned from fontconfig doesnʼt indicate anything
> specific we could use, but itʼs possible to modify the pattern we use
> for requesting. The following patch against emacs-26 fixes the crash
> for me (Emacs ends up using "Noto Emoji"). Definitely not intended to
> be applied to emacs-26.
> 
> modified   src/ftfont.c
> @@ -764,6 +764,8 @@ ftfont_spec_pattern (Lisp_Object spec, char *otlayout, struct OpenTypeSpec **ots
>    if (scalable >= 0
>        && ! FcPatternAddBool (pattern, FC_SCALABLE, scalable ? FcTrue : FcFalse))
>      goto err;
> +  /* We really don't like color fonts, they cause Xft crashes.  */
> +  FcPatternAddBool(pattern, FC_COLOR, FcFalse);
>  
>    goto finish;

Thanks!

Jan, can you see if this patch fixes the problem for you?

If Jan says it does fix the problem, I think we should install this on
master.  What do you think about having this conditioned on a variable
exposed to Lisp, as a "fire escape" in case there are some situations
where users might want these fonts anyway?

Also, we should probably condition this by HAVE_XFT, since AFAIU the
problem is only relevant to that build?

bug#30874: 27.0.50; Emacs crashes

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Until someone fixes
>> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=20890>, Cairo is
>> basically unusable for me even without the redisplay issues.
>
> That part of cleanup_vector is under suspicion since it was born, see
> "git -L" reports about that function.  Perhaps the easiest band-aid
> (or maybe it's a real fix) would be to disable this part:
>
>   if (PSEUDOVECTOR_TYPEP (&vector->header, PVEC_FONT)
>       && ((vector->header.size & PSEUDOVECTOR_SIZE_MASK)
> 	  == FONT_OBJECT_MAX))
>     {
>       struct font_driver const *drv = ((struct font *) vector)->driver;
>
>       /* The font driver might sometimes be NULL, e.g. if Emacs was
> 	 interrupted before it had time to set it up.  */
>       if (drv)
> 	{
> 	  /* Attempt to catch subtle bugs like Bug#16140.  */
> 	  eassert (valid_font_driver (drv));
> 	  drv->close ((struct font *) vector);
> 	}
>     }
>
> when the font backend is one of those which use ftfont_close.  Or
> maybe just make ftfont_close return without doing anything if it is
> called from GC.

Iʼll look into that. I assume thereʼs an 'in_gc' variable we can check.

>> > AFAIK, there's no "fallback" per se.  Whenever the already-loaded
>> > fonts don't support a character, Emacs looks for the fonts that do
>> > using the "match" method.  If we always fail these fonts in that
>> > method, they will never be used.
>> 
>> Yes, I was confused about what was happening. This explains why I was
>> not getting Symbola as well: that font doesnʼt have a glyph for #x274c
>
> Symbola I have installed here does have a glyph for that character,
> FWIW.

Now Iʼm thoroughly confused as to what's happening. Eg LibreOffice
quite happily uses Symbola, so it has the glyph, but I see Emacs
skipping past Symbola until it arrives at VL Gothic. Itʼs not a big
deal though, I doubt itʼs a bug.

>> modified   src/ftfont.c
>> @@ -764,6 +764,8 @@ ftfont_spec_pattern (Lisp_Object spec, char *otlayout, struct OpenTypeSpec **ots
>>    if (scalable >= 0
>>        && ! FcPatternAddBool (pattern, FC_SCALABLE, scalable ? FcTrue : FcFalse))
>>      goto err;
>> +  /* We really don't like color fonts, they cause Xft crashes.  */
>> +  FcPatternAddBool(pattern, FC_COLOR, FcFalse);
>>  
>>    goto finish;
>
> Thanks!
>
> Jan, can you see if this patch fixes the problem for you?
>
> If Jan says it does fix the problem, I think we should install this on
> master.  What do you think about having this conditioned on a variable
> exposed to Lisp, as a "fire escape" in case there are some situations
> where users might want these fonts anyway?

I thought Xft had no real support for displaying these fonts anyway?

> Also, we should probably condition this by HAVE_XFT, since AFAIU the
> problem is only relevant to that build?

I think thatʼs right. At least the cairo build doesnʼt crash with the
reproduction recipe.

Robert

bug#30874: 27.0.50; Emacs crashes

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 30874@debbugs.gnu.org,  jsynacek@redhat.com
> Date: Fri, 30 Mar 2018 15:00:43 +0200
> 
> > That part of cleanup_vector is under suspicion since it was born, see
> > "git -L" reports about that function.  Perhaps the easiest band-aid
> > (or maybe it's a real fix) would be to disable this part:
> >
> >   if (PSEUDOVECTOR_TYPEP (&vector->header, PVEC_FONT)
> >       && ((vector->header.size & PSEUDOVECTOR_SIZE_MASK)
> > 	  == FONT_OBJECT_MAX))
> >     {
> >       struct font_driver const *drv = ((struct font *) vector)->driver;
> >
> >       /* The font driver might sometimes be NULL, e.g. if Emacs was
> > 	 interrupted before it had time to set it up.  */
> >       if (drv)
> > 	{
> > 	  /* Attempt to catch subtle bugs like Bug#16140.  */
> > 	  eassert (valid_font_driver (drv));
> > 	  drv->close ((struct font *) vector);
> > 	}
> >     }
> >
> > when the font backend is one of those which use ftfont_close.  Or
> > maybe just make ftfont_close return without doing anything if it is
> > called from GC.
> 
> Iʼll look into that. I assume thereʼs an 'in_gc' variable we can check.

Yes, it's called gc_in_progress.

> > Symbola I have installed here does have a glyph for that character,
> > FWIW.
> 
> Now Iʼm thoroughly confused as to what's happening. Eg LibreOffice
> quite happily uses Symbola, so it has the glyph, but I see Emacs
> skipping past Symbola until it arrives at VL Gothic. Itʼs not a big
> deal though, I doubt itʼs a bug.

If VL Gothic has a glyph for that character, it is not a bug.

> > If Jan says it does fix the problem, I think we should install this on
> > master.  What do you think about having this conditioned on a variable
> > exposed to Lisp, as a "fire escape" in case there are some situations
> > where users might want these fonts anyway?
> 
> I thought Xft had no real support for displaying these fonts anyway?

I'm not sure it's about the font, it could be about some glyphs of the
font.  You are probably right, but IME leaving a variable to get back
previous behavior is good policy; at the very least, it makes it easy
to ask users who complain about related problems to see if this
particular change is the culprit without having to rebuild Emacs.

> > Also, we should probably condition this by HAVE_XFT, since AFAIU the
> > problem is only relevant to that build?
> 
> I think thatʼs right. At least the cairo build doesnʼt crash with the
> reproduction recipe.

Thanks.

bug#30874: 27.0.50; Emacs crashes

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

> Yes, it's called gc_in_progress.

Iʼm testing the following, which fixes the 20890 crash for me when
using Cairo.

diff --git i/src/ftfont.c w/src/ftfont.c
index c2e093e633..89c07e1f21 100644
--- i/src/ftfont.c
+++ w/src/ftfont.c
@@ -1242,6 +1242,11 @@ ftfont_close (struct font *font)
   struct ftfont_info *ftfont_info = (struct ftfont_info *) font;
   Lisp_Object val, cache;
 
+#ifdef USE_CAIRO
+  /* Bug#20890 workaround.  */
+  if (gc_in_progress)
+    return;
+#endif
   val = Fcons (font->props[FONT_FILE_INDEX], make_number (ftfont_info->index));
   cache = ftfont_lookup_cache (val, FTFONT_CACHE_FOR_FACE);
   eassert (CONSP (cache));

> I'm not sure it's about the font, it could be about some glyphs of the
> font.  You are probably right, but IME leaving a variable to get back
> previous behavior is good policy; at the very least, it makes it easy
> to ask users who complain about related problems to see if this
> particular change is the culprit without having to rebuild Emacs.
>
>> > Also, we should probably condition this by HAVE_XFT, since AFAIU the
>> > problem is only relevant to that build?

This is what Iʼm using at the moment. I can put the variable in
syms_of_xftfont if you prefer.

diff --git i/src/ftfont.c w/src/ftfont.c
index c2e093e633..2190186940 100644
--- i/src/ftfont.c
+++ w/src/ftfont.c
@@ -764,6 +764,13 @@ ftfont_spec_pattern (Lisp_Object spec, char *otlayout, struct OpenTypeSpec **ots
   if (scalable >= 0
       && ! FcPatternAddBool (pattern, FC_SCALABLE, scalable ? FcTrue : FcFalse))
     goto err;
+#ifdef HAVE_XFT
+  /* We really don't like color fonts, they cause Xft crashes.  See
+     bug#30874.  */
+  if (Vxft_ignore_color_fonts
+      && ! FcPatternAddBool(pattern, FC_COLOR, FcFalse))
+    goto err;
+#endif
 
   goto finish;
 
@@ -2735,6 +2742,14 @@ syms_of_ftfont (void)
   DEFSYM (Qsans, "sans");
   DEFSYM (Qsans__serif, "sans serif");
 
+#ifdef HAVE_XFT
+  DEFVAR_BOOL ("xft-ignore-color-fonts",
+	       Vxft_ignore_color_fonts,
+     doc: /* Non-nil means don't query fontconfig for color fonts,
+since they often cause Xft crashes. bug#30874.  */);
+  Vxft_ignore_color_fonts = 1;
+#endif
+
   staticpro (&freetype_font_cache);
   freetype_font_cache = list1 (Qt);
 

bug#30874: 27.0.50; Emacs crashes

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: 30874@debbugs.gnu.org,  jsynacek@redhat.com
> Date: Sat, 31 Mar 2018 15:55:13 +0200
> 
> Iʼm testing the following, which fixes the 20890 crash for me when
> using Cairo.
> 
> diff --git i/src/ftfont.c w/src/ftfont.c
> index c2e093e633..89c07e1f21 100644
> --- i/src/ftfont.c
> +++ w/src/ftfont.c
> @@ -1242,6 +1242,11 @@ ftfont_close (struct font *font)
>    struct ftfont_info *ftfont_info = (struct ftfont_info *) font;
>    Lisp_Object val, cache;
>  
> +#ifdef USE_CAIRO
> +  /* Bug#20890 workaround.  */
> +  if (gc_in_progress)
> +    return;
> +#endif
>    val = Fcons (font->props[FONT_FILE_INDEX], make_number (ftfont_info->index));
>    cache = ftfont_lookup_cache (val, FTFONT_CACHE_FOR_FACE);
>    eassert (CONSP (cache));

This LGTM, thanks.

> >> > Also, we should probably condition this by HAVE_XFT, since AFAIU the
> >> > problem is only relevant to that build?
> 
> This is what Iʼm using at the moment. I can put the variable in
> syms_of_xftfont if you prefer.
> 
> diff --git i/src/ftfont.c w/src/ftfont.c
> index c2e093e633..2190186940 100644
> --- i/src/ftfont.c
> +++ w/src/ftfont.c
> @@ -764,6 +764,13 @@ ftfont_spec_pattern (Lisp_Object spec, char *otlayout, struct OpenTypeSpec **ots
>    if (scalable >= 0
>        && ! FcPatternAddBool (pattern, FC_SCALABLE, scalable ? FcTrue : FcFalse))
>      goto err;
> +#ifdef HAVE_XFT
> +  /* We really don't like color fonts, they cause Xft crashes.  See
> +     bug#30874.  */
> +  if (Vxft_ignore_color_fonts
> +      && ! FcPatternAddBool(pattern, FC_COLOR, FcFalse))
> +    goto err;
> +#endif
>  
>    goto finish;
>  
> @@ -2735,6 +2742,14 @@ syms_of_ftfont (void)
>    DEFSYM (Qsans, "sans");
>    DEFSYM (Qsans__serif, "sans serif");
>  
> +#ifdef HAVE_XFT
> +  DEFVAR_BOOL ("xft-ignore-color-fonts",
> +	       Vxft_ignore_color_fonts,
> +     doc: /* Non-nil means don't query fontconfig for color fonts,
> +since they often cause Xft crashes. bug#30874.  */);
> +  Vxft_ignore_color_fonts = 1;
> +#endif
> +
>    staticpro (&freetype_font_cache);
>    freetype_font_cache = list1 (Qt);

It can stay in ftfont.c, but please make the second hunk
unconditional, so that the variable is known and available in all the
builds, just say in the doc string that this variable has effect only
on the xftfont backend.  I have bad experience with variables that are
only defined in some configurations: it means both trouble for users
who use more than one configuration and more maintenance headaches.
Come to think of it, maybe it's best to move DEFVAR_BOOL to font.c,
for that very reason.

Thanks.

bug#30874: 27.0.50; Emacs crashes

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: 30874@debbugs.gnu.org,  jsynacek@redhat.com
>> Date: Sat, 31 Mar 2018 15:55:13 +0200
>> 
>> Iʼm testing the following, which fixes the 20890 crash for me when
>> using Cairo.
>> 
>> diff --git i/src/ftfont.c w/src/ftfont.c
>> index c2e093e633..89c07e1f21 100644
>> --- i/src/ftfont.c
>> +++ w/src/ftfont.c
>> @@ -1242,6 +1242,11 @@ ftfont_close (struct font *font)
>>    struct ftfont_info *ftfont_info = (struct ftfont_info *) font;
>>    Lisp_Object val, cache;
>>  
>> +#ifdef USE_CAIRO
>> +  /* Bug#20890 workaround.  */
>> +  if (gc_in_progress)
>> +    return;
>> +#endif
>>    val = Fcons (font->props[FONT_FILE_INDEX], make_number (ftfont_info->index));
>>    cache = ftfont_lookup_cache (val, FTFONT_CACHE_FOR_FACE);
>>    eassert (CONSP (cache));
>
> This LGTM, thanks.
>

Iʼll follow up in bug 20890.

>
> It can stay in ftfont.c, but please make the second hunk
> unconditional, so that the variable is known and available in all the
> builds, just say in the doc string that this variable has effect only
> on the xftfont backend.  I have bad experience with variables that are
> only defined in some configurations: it means both trouble for users
> who use more than one configuration and more maintenance headaches.
> Come to think of it, maybe it's best to move DEFVAR_BOOL to font.c,
> for that very reason.

OK, adjusted accordingly.

Robert

bug#30874: 27.0.50; Emacs crashes

[Jan Synacek]

On Fri, Mar 30, 2018 at 1:46 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> modified   src/ftfont.c
>> @@ -764,6 +764,8 @@ ftfont_spec_pattern (Lisp_Object spec, char *otlayout, struct OpenTypeSpec **ots
>>    if (scalable >= 0
>>        && ! FcPatternAddBool (pattern, FC_SCALABLE, scalable ? FcTrue : FcFalse))
>>      goto err;
>> +  /* We really don't like color fonts, they cause Xft crashes.  */
>> +  FcPatternAddBool(pattern, FC_COLOR, FcFalse);
>>
>>    goto finish;
>
> Thanks!
>
> Jan, can you see if this patch fixes the problem for you?

Yes, it does fix the problem for me.

Cheers,
-- 
Jan Synacek
Software Engineer, Red Hat

bug#30874: 27.0.50; Emacs crashes

[Robert Pluim]

[-- Attachment #1: Type: text/plain, Size: 251 bytes --]

tags 30874 patch
quit

Jan Synacek <jsynacek@redhat.com> writes:
>
> Yes, it does fix the problem for me.

Thanks. Proposed patch for master attached. Eli, should I merge this
bugreport with 30045?  The patch fixes that crash for me as well.

Robert


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Ignore-color-fonts-when-using-Xft.patch --]
[-- Type: text/x-patch, Size: 2337 bytes --]

From 1efdd2b9a5cb3880e4878dbc7c918ccac9da2393 Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Tue, 3 Apr 2018 11:06:01 +0200
Subject: [PATCH] Ignore color fonts when using Xft
To: emacs-devel@gnu.org

* src/font.c (syms_of_font): New configuration variable
xft-ignore-color-fonts, default t.
* src/ftfont.c (ftfont_spec_pattern): Tell fontconfig to ignore
color fonts if xft-ignore-color-fonts is t.  Bug#30874
---
 etc/NEWS     | 6 ++++++
 src/font.c   | 7 +++++++
 src/ftfont.c | 7 +++++++
 3 files changed, 20 insertions(+)

diff --git a/etc/NEWS b/etc/NEWS
index fd1d04b8a0..177af9f088 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -77,6 +77,12 @@ work right without some adjustment:
 \f
 * Changes in Emacs 27.1
 
+---
+** New variable 'xft-ignore-color-fonts'.
+Default t means don't try to load color fonts when using Xft, as they
+often cause crashes.  Set it to nil if you really need those fonts.
+(Bug#30874)
+
 ---
 ** The new option 'tooltip-resize-echo-area' avoids truncating tooltip text
 on GUI frames when tooltips are displayed in the echo area.  Instead,
diff --git a/src/font.c b/src/font.c
index a6d3f5d479..fa89805419 100644
--- a/src/font.c
+++ b/src/font.c
@@ -5473,6 +5473,13 @@ Disabling compaction of font caches might enlarge the Emacs memory
 footprint in sessions that use lots of different fonts.  */);
   inhibit_compacting_font_caches = 0;
 
+  DEFVAR_BOOL ("xft-ignore-color-fonts",
+	       Vxft_ignore_color_fonts,
+	       doc: /*
+Non-nil means don't query fontconfig for color fonts, since they often
+cause Xft crashes.  Only has an effect in Xft builds.  Bug#30874.  */);
+  Vxft_ignore_color_fonts = 1;
+
 #ifdef HAVE_WINDOW_SYSTEM
 #ifdef HAVE_FREETYPE
   syms_of_ftfont ();
diff --git a/src/ftfont.c b/src/ftfont.c
index c2e093e633..24a92dd52e 100644
--- a/src/ftfont.c
+++ b/src/ftfont.c
@@ -764,6 +764,13 @@ ftfont_spec_pattern (Lisp_Object spec, char *otlayout, struct OpenTypeSpec **ots
   if (scalable >= 0
       && ! FcPatternAddBool (pattern, FC_SCALABLE, scalable ? FcTrue : FcFalse))
     goto err;
+#ifdef HAVE_XFT
+  /* We really don't like color fonts, they cause Xft crashes.  See
+     Bug#30874.  */
+  if (Vxft_ignore_color_fonts
+      && ! FcPatternAddBool(pattern, FC_COLOR, FcFalse))
+    goto err;
+#endif
 
   goto finish;
 
-- 
2.17.0.rc1.35.g90bbd502d

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
> Date: Tue, 03 Apr 2018 11:22:05 +0200
> 
> Jan Synacek <jsynacek@redhat.com> writes:
> >
> > Yes, it does fix the problem for me.
> 
> Thanks. Proposed patch for master attached.

Thanks, the patch LGTM, but I would omit the reference to the bug
number from the doc string.  I think it's enough to have the bug
referenced by the commit log message and in the only place where the
variable is used.

> Eli, should I merge this bugreport with 30045?  The patch fixes that
> crash for me as well.

Yes, please merge them, and please mention bug#30045 in the log
message.

bug#30874: 27.0.50; Emacs crashes

[Robert Pluim]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  30874@debbugs.gnu.org
>> Date: Tue, 03 Apr 2018 11:22:05 +0200
>> 
>> Jan Synacek <jsynacek@redhat.com> writes:
>> >
>> > Yes, it does fix the problem for me.
>> 
>> Thanks. Proposed patch for master attached.
>
> Thanks, the patch LGTM, but I would omit the reference to the bug
> number from the doc string.  I think it's enough to have the bug
> referenced by the commit log message and in the only place where the
> variable is used.
>
>> Eli, should I merge this bugreport with 30045?  The patch fixes that
>> crash for me as well.
>
> Yes, please merge them, and please mention bug#30045 in the log
> message.

OK, pushed as 408bf21a8c, boldly closing the bug.

Robert

bug#30874: 27.0.50; Emacs crashes

[Jan Synacek]

On Tue, Mar 27, 2018 at 5:02 AM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: 30874@debbugs.gnu.org,  jsynacek@redhat.com
>> Date: Tue, 27 Mar 2018 00:16:37 +0200
>>
>> I added some debug to libXft. When the set-fonset-font is executed,
>> Xft loads /usr/share/fonts/eosrei-emojione/emojione-android.ttf. Some
>> of the glyphs in that font cause Xft to allocate 16384 bytes of bitmap
>> buffer, which is what causes the problems [1]. If I move that font out
>> of the way I get no crash. I think we're back to a
>> variant of Bug #30045.
>
> Thanks!
>
> Jan, do you also see this font loaded in your case?

Yes, I do.

-- 
Jan Synacek
Software Engineer, Red Hat