bug#43177: Bug: Emacs 27.1 hangs forever in `FcCharSetSubtractCount' from '/usr/lib/libfontconfig.so.1'

[Alexander Shukaev]

Hi,

With latest Emacs, I have a sporadic hang issue when either opening a
file or scrolling a buffer. The best part is that it's impossible to
get break back to evaluation loop of Emacs even with 'USR2' signal.
That is when 'USR2' is sent, it does show "Entering debugger...", though
it remains frozen afterwards. Resending 'USR2' leads to the same
outcome. One thing is for certain, every time 'USR2' is sent into such
a hang, the stack traceback leads to `FcCharSetSubtractCount' from
'/usr/lib/libfontconfig.so.1':

Thread 1 "emacs" received signal SIGUSR2, User defined signal 2.
0x00007ffff60f8211 in FcCharSetSubtractCount ()
from /usr/lib/libfontconfig.so.1
(gdb) bt
#0 0x00007ffff60f8211 in FcCharSetSubtractCount
() at /usr/lib/libfontconfig.so.1
#1 0x00007ffff61057df in ()
at /usr/lib/libfontconfig.so.1
#2 0x00007ffff6105c05 in ()
at /usr/lib/libfontconfig.so.1
#3 0x00007ffff6105fa7 in ()
at /usr/lib/libfontconfig.so.1
#4 0x00007ffff61060b4 in ()
at /usr/lib/libfontconfig.so.1
#5 0x00007ffff6106ef8 in FcFontMatch ()
at /usr/lib/libfontconfig.so.1
#6 0x00005555558e523c in ftcrfont_open
(f=0x5555563d5f50, entity=..., pixel_size=15)
at ftcrfont.c:137
#7 0x00005555558466c8 in font_open_entity
(f=0x5555563d5f50, entity=..., pixel_size=13)
at font.c:2913
#8 0x0000555555848372 in font_open_for_lface
(f=0x5555563d5f50, entity=..., attrs=0x55555cd757d0, spec=...) at
font.c:3350
#9 0x00005555558eaf63 in fontset_find_font
(fontset=..., c=25253, face=0x55555cd757d0, charset_id=-1,
fallback=true) at fontset.c:713
#10 0x00005555558eb632 in fontset_font
(fontset=..., c=25253, face=0x55555cd757d0, id=-1) at fontset.c:806
#11 0x00005555558ec00b in face_for_char
(f=0x5555563d5f50, face=0x55555cd757d0, c=25253, pos=257429,
object=...) at fontset.c:996
#12 0x00005555555bd121 in FACE_FOR_CHAR
(f=0x5555563d5f50, face=0x55555cd757d0, character=25253,
pos=257429, object=...)
at dispextern.h:1882
#13 0x00005555555db943 in get_next_display_element (it=0x7ffffffe5290)
at xdisp.c:7753
#14 0x00005555555df551 in move_it_in_display_line_to
(it=0x7ffffffe5290, to_charpos=-1, to_x=-1, op=(unknown: 0)) at
xdisp.c:9244
#15 0x00005555555e291d in move_it_to
(it=0x7ffffffe5290, to_charpos=-1, to_x=-1, to_y=-1, to_vpos=1,
op=4) at xdisp.c:9853
#16 0x00005555555e4157 in move_it_by_lines
(it=0x7ffffffe5290, dvpos=1) at xdisp.c:10386
#17 0x00005555555c1484 in line_bottom_y
(it=0x7ffffffe5290) at xdisp.c:1451
#18 0x00005555555c257e in pos_visible_p
(w=0x5555563d6190, charpos=257337, x=0x7ffffffe9f3c,
y=0x7ffffffe9f38, rtop=0x7ffffffe9f4c, rbot=0x7ffffffe9f48,
rowh=0x7ffffffe9f44, vpos=0x7ffffffe9f40) at xdisp.c:1753
#19 0x000055555564e225 in Fpos_visible_in_window_p (pos=..., window=...,
partially=...)
at window.c:1910
#20 0x0000555555756d97 in Fposn_at_point
(pos=..., window=...) at keyboard.c:11249
#21 0x000055555582158d in funcall_subr
(subr=0x555555de5c20 <Sposn_at_point>, numargs=2,
args=0x7ffffffea1a8) at eval.c:2870
--Type <RET> for more, q to quit, c to continue without paging--
#22 0x0000555555820fc9 in Ffuncall
(nargs=3, args=0x7ffffffea1a0) at eval.c:2795
#23 0x000055555587d61a in exec_byte_code
(bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1,
args=0x7ffffffea858)
at bytecode.c:632
#24 0x0000555555821815 in fetch_and_exec_byte_code (fun=...,
syms_left=..., nargs=1, args=0x7ffffffea850) at eval.c:2917
#25 0x0000555555821cce in funcall_lambda
(fun=..., nargs=1, arg_vector=0x7ffffffea850)
at eval.c:2998
#26 0x000055555582100d in Ffuncall
(nargs=2, args=0x7ffffffea848) at eval.c:2797
#27 0x000055555587d61a in exec_byte_code
(bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=2,
args=0x7ffffffeae08)
at bytecode.c:632
#28 0x0000555555821815 in fetch_and_exec_byte_code (fun=...,
syms_left=..., nargs=2, args=0x7ffffffeadf8) at eval.c:2917
#29 0x0000555555821cce in funcall_lambda
(fun=..., nargs=2, arg_vector=0x7ffffffeadf8)
at eval.c:2998
#30 0x000055555582100d in Ffuncall
(nargs=3, args=0x7ffffffeadf0) at eval.c:2797
#31 0x000055555587d61a in exec_byte_code
(bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=2,
args=0x7ffffffeb348)
at bytecode.c:632
#32 0x0000555555821815 in fetch_and_exec_byte_code (fun=...,
syms_left=..., nargs=2, args=0x7ffffffeb338) at eval.c:2917
#33 0x0000555555821cce in funcall_lambda
(fun=..., nargs=2, arg_vector=0x7ffffffeb338)
at eval.c:2998
#34 0x000055555582100d in Ffuncall
(nargs=3, args=0x7ffffffeb330) at eval.c:2797
#35 0x000055555587d61a in exec_byte_code
(bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=2,
args=0x7ffffffeb908)
at bytecode.c:632
#36 0x0000555555821815 in fetch_and_exec_byte_code (fun=...,
syms_left=..., nargs=2, args=0x7ffffffeb8f8) at eval.c:2917
#37 0x0000555555821cce in funcall_lambda
(fun=..., nargs=2, arg_vector=0x7ffffffeb8f8)
at eval.c:2998
#38 0x000055555582100d in Ffuncall
(nargs=3, args=0x7ffffffeb8f0) at eval.c:2797
#39 0x000055555587d61a in exec_byte_code
(bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=2,
args=0x7ffffffebf78)
at bytecode.c:632
#40 0x0000555555821815 in fetch_and_exec_byte_code (fun=...,
syms_left=..., nargs=2, args=0x7ffffffebf78) at eval.c:2917
#41 0x0000555555821cce in funcall_lambda
(fun=..., nargs=2, arg_vector=0x7ffffffebf78)
at eval.c:2998
--Type <RET> for more, q to quit, c to continue without paging--
#42 0x000055555582100d in Ffuncall
(nargs=3, args=0x7ffffffebf70) at eval.c:2797
#43 0x0000555555820069 in Fapply
(nargs=2, args=0x7ffffffec020) at eval.c:2425
#44 0x000055555582075e in apply1
(fn=..., arg=...) at eval.c:2641
#45 0x00005555558194bf in call_debugger (arg=...)
at eval.c:339
#46 0x000055555581dde8 in maybe_call_debugger
(conditions=..., sig=..., data=...)
at eval.c:1831
#47 0x000055555581d689 in signal_or_quit
(error_symbol=..., data=..., keyboard_quit=true) at eval.c:1667
#48 0x000055555581d350 in quit () at eval.c:1577
#49 0x000055555581d23b in process_quit_flag ()
at eval.c:1524
#50 0x000055555581d281 in maybe_quit ()
at eval.c:1544
#51 0x000055555582df32 in Fassq
(key=..., alist=...) at fns.c:1609
#52 0x00005555556ae6ad in uniprop_table
(prop=...) at chartab.c:1284
#53 0x00005555557af2aa in prepare_casing_context
(ctx=0x7ffffffec320, flag=CASE_UP, inbuffer=false) at casefiddle.c:72
#54 0x00005555557afac6 in casify_object
(flag=CASE_UP, obj=...) at casefiddle.c:326
#55 0x00005555557afb9d in Fupcase (obj=...)
at casefiddle.c:349
#56 0x000055555582a190 in Fcompare_strings
(str1=..., start1=..., end1=..., str2=..., start2=..., end2=...,
ignore_case=...) at fns.c:320
#57 0x00005555557966f2 in Fassoc_string
(key=..., list=..., case_fold=...)
at minibuf.c:1855
#58 0x0000555555847bbb in font_find_for_lface
(f=0x5555563d5f50, attrs=0x55555cd757d0, spec=..., c=-1) at font.c:3250
#59 0x00005555558ead1e in fontset_find_font
(fontset=..., c=25253, face=0x55555cd757d0, charset_id=-1,
fallback=true) at fontset.c:660
#60 0x00005555558eb632 in fontset_font
(fontset=..., c=25253, face=0x55555cd757d0, id=-1) at fontset.c:806
#61 0x00005555558ec00b in face_for_char
(f=0x5555563d5f50, face=0x55555cd757d0, c=25253, pos=257429,
object=...) at fontset.c:996
#62 0x00005555555bd121 in FACE_FOR_CHAR
(f=0x5555563d5f50, face=0x55555cd757d0, character=25253,
pos=257429, object=...)
at dispextern.h:1882
#63 0x00005555555db943 in get_next_display_element (it=0x7fffffff5160)
at xdisp.c:7753
#64 0x00005555555df551 in move_it_in_display_line_to
(it=0x7fffffff5160, to_charpos=-1, to_x=-1, op=(unknown: 0)) at
xdisp.c:9244
#65 0x00005555555e291d in move_it_to
(it=0x7fffffff5160, to_charpos=-1, to_x=-1, to--Type <RET> for
more, q to quit, c to continue without paging--
_y=-1, to_vpos=1, op=4) at xdisp.c:9853
#66 0x00005555555e4157 in move_it_by_lines
(it=0x7fffffff5160, dvpos=1) at xdisp.c:10386
#67 0x00005555555c1484 in line_bottom_y
(it=0x7fffffff5160) at xdisp.c:1451
#68 0x00005555555c257e in pos_visible_p
(w=0x5555563d6190, charpos=257337, x=0x7fffffff9e20,
y=0x7fffffff9e1c, rtop=0x7fffffff9e18, rbot=0x7fffffff9e14,
rowh=0x7fffffff9e10, vpos=0x7fffffff9e0c) at xdisp.c:1753
#69 0x0000555555658633 in window_scroll_pixel_based (window=..., n=1,
whole=true, noerror=false)
at window.c:5549
#70 0x00005555556582ec in window_scroll
(window=..., n=1, whole=true, noerror=false)
at window.c:5471
#71 0x000055555565b461 in scroll_command
(window=..., n=..., direction=1)
at window.c:6177
#72 0x000055555565b5c8 in Fscroll_up (arg=...)
at window.c:6204
#73 0x0000555555821569 in funcall_subr
(subr=0x555555de1960 <Sscroll_up>, numargs=1, args=0x7fffffffc718)
at eval.c:2868
#74 0x0000555555820fc9 in Ffuncall
(nargs=2, args=0x7fffffffc710) at eval.c:2795
#75 0x000055555587d61a in exec_byte_code
(bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1,
args=0x7fffffffcd28)
at bytecode.c:632
#76 0x0000555555821815 in fetch_and_exec_byte_code (fun=...,
syms_left=..., nargs=1, args=0x7fffffffcd20) at eval.c:2917
#77 0x0000555555821cce in funcall_lambda
(fun=..., nargs=1, arg_vector=0x7fffffffcd20)
at eval.c:2998
#78 0x000055555582100d in Ffuncall
(nargs=2, args=0x7fffffffcd18) at eval.c:2797
#79 0x0000555555814e31 in Ffuncall_interactively
(nargs=2, args=0x7fffffffcd18)
at callint.c:253
#80 0x000055555582143b in funcall_subr
(subr=0x555555dec8e0 <Sfuncall_interactively>, numargs=2,
args=0x7fffffffcd18) at eval.c:2848
#81 0x0000555555820fc9 in Ffuncall
(nargs=3, args=0x7fffffffcd10) at eval.c:2795
#82 0x000055555581760c in Fcall_interactively
(function=..., record_flag=..., keys=...)
at callint.c:779
#83 0x00005555558215bc in funcall_subr
(subr=0x555555dec920 <Scall_interactively>, numargs=3,
args=0x7fffffffd0b0) at eval.c:2873
#84 0x0000555555820fc9 in Ffuncall
(nargs=4, args=0x7fffffffd0a8) at eval.c:2795
#85 0x000055555587d61a in exec_byte_code
(bytestr=..., vector=..., maxdepth=..., args_template=..., nargs=1,
args=0x7fffffffd600)
at bytecode.c:632
#86 0x0000555555821815 in fetch_and_exec_byte_code (fun=...,
syms_left=..., nargs=1, args=0x7fffffff--Type <RET> for more, q to quit,
c to continue without paging--
d5f8) at eval.c:2917
#87 0x0000555555821cce in funcall_lambda
(fun=..., nargs=1, arg_vector=0x7fffffffd5f8)
at eval.c:2998
#88 0x000055555582100d in Ffuncall
(nargs=2, args=0x7fffffffd5f0) at eval.c:2797
#89 0x00005555558207d8 in call1
(fn=..., arg1=...) at eval.c:2655
#90 0x000055555573b7f3 in command_loop_1 ()
at keyboard.c:1463
#91 0x000055555581cc20 in internal_condition_case
(bfun=0x55555573af39 <command_loop_1>, handlers=...,
hfun=0x55555573a516 <cmd_error>)
at eval.c:1356
#92 0x000055555573ab17 in command_loop_2
(ignore=...) at keyboard.c:1091
#93 0x000055555581c045 in internal_catch
(tag=..., func=0x55555573aaea <command_loop_2>, arg=...) at eval.c:1117
#94 0x000055555573aab6 in command_loop ()
at keyboard.c:1070
#95 0x0000555555739ff9 in recursive_edit_1 ()
at keyboard.c:714
#96 0x000055555573a1f5 in Frecursive_edit ()
at keyboard.c:786
#97 0x0000555555735f3a in main
(argc=1, argv=0x7fffffffdae8) at emacs.c:2047

The package for 'fontconfig' is

local/fontconfig 2:2.13.91+48+gfcb0420-2
Library for configuring and customizing font access

For me, it's definitely a blocker for an upgrade to this new Emacs.
Maybe the issue is with 'fontconfig', in any case, would be nice to
understand what's happening here. Please, advise.

Kind regards,
Alexander

[Robert Pluim]

>>>>> On Thu, 3 Sep 2020 09:18:53 +0200, Alexander Shukaev <em...@Alexander.Shukaev.name> said:

Alexander> Hi,
Alexander> With latest Emacs, I have a sporadic hang issue when either opening a
Alexander> file or scrolling a buffer. The best part is that it's impossible to
Alexander> get break back to evaluation loop of Emacs even with 'USR2'
Alexander> signal. That is when 'USR2' is sent, it does show "Entering
Alexander> debugger...", though it remains frozen afterwards. Resending 'USR2'
Alexander> leads to the same outcome. One thing is for certain, every time
Alexander> 'USR2' is sent into such a hang, the stack traceback leads to
Alexander> `FcCharSetSubtractCount' from '/usr/lib/libfontconfig.so.1':

If you've still got this in gdb, can you go to frame #6 and do

pp entity

(this is assuming you've sourced the .gdbinit in src/)

That will tell us which font weʼre trying to open. Perhaps itʼs a bad
font or fontconfig configuration.

Robert

[Pip Cet]

Is this bug #40733, maybe?

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40733

[Alexander Shukaev]

Not sure how to debug further:

(gdb) f 7
#7 0x0000555555aa48f0 in ftcrfont_open (f=0x555556521410,
entity=XIL(0x55555aa0d7c5), pixel_size=21) at ftcrfont.c:137
137 match = FcFontMatch (NULL, pat, &result);
(gdb) p pat
$1 = (FcPattern *) 0x55556845efb0
(gdb) p *pat
$2 = <incomplete type>
(gdb) info locals
result = FcResultNoMatch
val = XIL(0x5555658e2a23)
filename = XIL(0x55555ba4d1e4)
font_object = XIL(0x555565b558a5)
pat = 0x55556845efb0
match = 0x55555be76210
ftcrfont_info = 0x555565b558a0
font = 0x555565b558a0
size = 21
font_face = 0x55555ef899f0
extents = {
ascent = 18,
descent = 3.0000000000000004,
height = 20,
max_x_advance = 4.6355841119114706e-310,
max_y_advance = 6.9533558052579579e-310
}
ft_face = 0x55555a74ab50
matrix = 0x555564edf50f
font_matrix = {
xx = 4.6355841119112235e-310,
yx = 4.6355841119114706e-310,
xy = 4.6355707518995349e-310,
yy = 2.000000208656282,
x0 = 6.9533558052595389e-310,
y0 = 4.6355707518839718e-310
}
ctm = {
xx = 4.6355707529419146e-310,
yx = 4.6355841119114706e-310,
xy = 6.9533558052611199e-310,
yy = 4.6355707529569342e-310,
x0 = 0,
y0 = 4.6355841119114706e-310
}
options = 0x555557584e40
scaled_font = 0x555558791990
stack_glyph = {
index = 127,
x = 0,
y = 0
}

[Alexander Shukaev]

Ah, just noticed your suggestion:

(gdb) pp entity
#<font-entity ftcrhb ADBO Adobe\ Blank nil iso10646-1 normal normal
normal 0 nil 100 0 ((:font-entity
"/usr/share/fonts/TTF/AdobeBlank-Regular.ttf" . 0))>

[Alexander Shukaev]

/usr/share/fonts/TTF/AdobeBlank-Regular.ttf is owned by
ttf-google-fonts-git 20171026-1

I will try updating it now and see if it fixes the issue. However, even
if it does, I have a bunch of follow-up questions:

1. How to protect Emacs from having that issue again regardless of
broken/out-dated fonts? Can I somehow, for example, exclude such fonts
from consideration by Emacs?
2. Why was this font queried at all in the first place? I don't use
this font.

[Robert Pluim]

>>>>> On Thu, 3 Sep 2020 11:02:16 +0200, Alexander Shukaev <em...@Alexander.Shukaev.name> said:

Alexander> /usr/share/fonts/TTF/AdobeBlank-Regular.ttf is owned by
Alexander> ttf-google-fonts-git 20171026-1

Looks like Pip's crystal ball was right, thatʼs the same font
impicated in Bug#40733

Alexander> I will try updating it now and see if it fixes the issue. However,
Alexander> even if it does, I have a bunch of follow-up questions:

Alexander> 1. How to protect Emacs from having that issue again regardless of
Alexander> broken/out-dated fonts? Can I somehow, for example, exclude such
Alexander> fonts from consideration by Emacs?

face-ignored-fonts is a variable defined in `C source code'.
Its value is nil

Probably introduced at or before Emacs version 21.1.

Documentation:
List of ignored fonts.
Each element is a regular expression that matches names of fonts to
ignore.

Alexander> 2. Why was this font queried at all in the first place? I don't use
Alexander> this font.

You donʼt use it, but fontconfig know about it, so it queries it when
Emacs queries fontconfig for available fonts covering a certain
codepoint.

Robert

[Alexander Shukaev]

Right, so briefly testing, I think the scrolling hang is gone thanks to

(add-to-list 'face-ignored-fonts "Adobe.*Blank")

However, hang from opening certain files is still there and is also
font-related, though with a different symptom:

Thread 1 "emacs" received signal SIGABRT, Aborted.
0x00007ffff5c0646f in poll () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff5c0646f in poll () at /usr/lib/libc.so.6
#1 0x00007ffff6e2a63b in () at /usr/lib/libxcb.so.1
#2 0x00007ffff6e2c08f in () at /usr/lib/libxcb.so.1
#3 0x00007ffff6e2c203 in xcb_wait_for_reply64 () at /usr/lib/libxcb.so.1
#4 0x00007ffff6e904b9 in _XReply () at /usr/lib/libX11.so.6
#5 0x00007ffff6e71e71 in () at /usr/lib/libX11.so.6
#6 0x00007ffff6e7254e in XLoadQueryFont () at /usr/lib/libX11.so.6
#7 0x0000555555a8d875 in xfont_supported_scripts
(display=0x555556594940, fontname=0x55556a79e428 "-misc-trirong
medium-medium-i-normal--0-0-0-0-p-0-iso10646-1",
props=XIL(0x7ffff27926e5), encoding=0x7ffff23ab8d0) at xfont.c:266
#8 0x0000555555a8e5eb in xfont_list_pattern (display=0x555556594940,
pattern=0x7fffffff6450 "-*-*-*-*-*-*-*-*-*-*-*-*-iso10646-1",
registry=XIL(0x84c0), script=XIL(0x2aaa9c470db0)) at xfont.c:441
#9 0x0000555555a8e94d in xfont_list (f=0x5555564db330,
spec=XIL(0x7ffff2794475)) at xfont.c:486
#10 0x0000555555983724 in font_list_entities (f=0x5555564db330,
spec=XIL(0x55556932a495)) at font.c:2794
#11 0x000055555598588c in font_find_for_lface (f=0x5555564db330,
attrs=0x555564a499c0, spec=XIL(0x5555568e6125), c=-1) at font.c:3285
#12 0x0000555555ab4a23 in fontset_find_font
(fontset=XIL(0x555569329a45), c=43695, face=0x555564a499c0,
charset_id=-1, fallback=false) at fontset.c:661
#13 0x0000555555ab514f in fontset_font (fontset=XIL(0x5555568a0d45),
c=43695, face=0x555564a499c0, id=-1) at fontset.c:783
#14 0x0000555555ab5cff in face_for_char (f=0x5555564db330,
face=0x555564a499c0, c=43695, pos=38, object=XIL(0)) at fontset.c:997
#15 0x00005555555d0b96 in FACE_FOR_CHAR (f=0x5555564db330,
face=0x555564a499c0, character=43695, pos=38, object=XIL(0)) at
dispextern.h:1891
#16 0x00005555555f091a in get_next_display_element (it=0x7fffffff8040)
at xdisp.c:7651
#17 0x0000555555626aae in display_line (it=0x7fffffff8040,
cursor_vpos=8) at xdisp.c:23222
#18 0x0000555555617030 in try_window (window=XIL(0x5555564db575),
pos=..., flags=1) at xdisp.c:19182
#19 0x0000555555613c67 in redisplay_window (window=XIL(0x5555564db575),
just_this_one_p=false) at xdisp.c:18600
#20 0x000055555560aefd in redisplay_window_0
(window=XIL(0x5555564db575)) at xdisp.c:16314
#21 0x000055555594c082 in internal_condition_case_1 (bfun=0x55555560aebb
<redisplay_window_0>, arg=XIL(0x5555564db575),
handlers=XIL(0x7ffff279a6f3), hfun=0x55555560ae83 <redisplay_window_error>)
at eval.c:1380
#22 0x000055555560ae55 in redisplay_windows (window=XIL(0x5555564db575))
at xdisp.c:16294
#23 0x000055555560ae06 in redisplay_windows (window=XIL(0x5555629c9865))
at xdisp.c:16288
#24 0x000055555560978e in redisplay_internal () at xdisp.c:15762
#25 0x000055555560712f in redisplay () at xdisp.c:14989
#26 0x00005555557e20ca in read_char (commandflag=1,
map=XIL(0x555569315a13), prev_event=XIL(0),
used_mouse_menu=0x7fffffffd3f5, end_time=0x0) at keyboard.c:2493
#27 0x00005555557f5a94 in read_key_sequence (keybuf=0x7fffffffd5e0,
prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true,
fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9553
#28 0x00005555557de249 in command_loop_1 () at keyboard.c:1350
#29 0x000055555594bfa5 in internal_condition_case (bfun=0x5555557ddda4
<command_loop_1>, handlers=XIL(0x90), hfun=0x5555557dd370 <cmd_error>)
at eval.c:1356
#30 0x00005555557dd97c in command_loop_2 (ignore=XIL(0)) at keyboard.c:1091
#31 0x000055555594b3ea in internal_catch (tag=XIL(0xd530),
func=0x5555557dd94e <command_loop_2>, arg=XIL(0)) at eval.c:1117
#32 0x00005555557dd919 in command_loop () at keyboard.c:1070
#33 0x00005555557dce47 in recursive_edit_1 () at keyboard.c:714
#34 0x00005555557dd046 in Frecursive_edit () at keyboard.c:786
#35 0x00005555557d313e in main (argc=1, argv=0x7fffffffda68) at emacs.c:2062

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb) f 7
#7 0x0000555555a8d875 in xfont_supported_scripts
(display=0x555556594940, fontname=0x55556a79e428 "-misc-trirong
medium-medium-i-normal--0-0-0-0-p-0-iso10646-1", props=XIL(0x7ffff27926e5),
encoding=0x7ffff23ab8d0) at xfont.c:266
266 xfont = XLoadQueryFont (display, fontname);
(gdb) pp fontname
#<INVALID_LISP_OBJECT 0x55556a79e428>
(gdb) pp fontname
#<INVALID_LISP_OBJECT 0x55556a79e428>
(gdb) p fontname
$3 = 0x55556a79e428 "-misc-trirong
medium-medium-i-normal--0-0-0-0-p-0-iso10646-1"
(gdb)

[Alexander Shukaev]

On 03/09/2020 11:40, Alexander Shukaev wrote:
> (gdb) f 7
> #7  0x0000555555a8d875 in xfont_supported_scripts
> (display=0x555556594940, fontname=0x55556a79e428 "-misc-trirong
> medium-medium-i-normal--0-0-0-0-p-0-iso10646-1", props=XIL(0x7ffff27926e5),
>     encoding=0x7ffff23ab8d0) at xfont.c:266
> 266          xfont = XLoadQueryFont (display, fontname);
> (gdb) pp fontname
> #<INVALID_LISP_OBJECT 0x55556a79e428>
> (gdb) pp fontname
> #<INVALID_LISP_OBJECT 0x55556a79e428>
> (gdb) p fontname
> $3 = 0x55556a79e428 "-misc-trirong
> medium-medium-i-normal--0-0-0-0-p-0-iso10646-1"
> (gdb)

It appears to always be different `fontname' here as I try multiple
times to reproduce. Maybe it's not really hanging but is merely
ultra-slow somehow in looping over the fonts here. Any ideas?

[Alexander Shukaev]

Hmm, right, waited for about a minute or so, and the file got opened
finally. Reopening it was instant as well as if something got
cached/loaded already. So any ideas how to speed things up here? I
don't think I've encountered that with 26.3...

[Robert Pluim]

>>>>> On Thu, 3 Sep 2020 11:40:07 +0200, Alexander Shukaev <em...@Alexander.Shukaev.name> said:
Alexander> Right, so briefly testing, I think the scrolling hang is gone thanks to

Alexander> (add-to-list 'face-ignored-fonts "Adobe.*Blank")

Alexander> However, hang from opening certain files is still there and is also
Alexander> font-related, though with a different symptom:

Alexander> Thread 1 "emacs" received signal SIGABRT, Aborted.
Alexander> 0x00007ffff5c0646f in poll () from /usr/lib/libc.so.6
Alexander> (gdb) bt
Alexander> #0 0x00007ffff5c0646f in poll () at /usr/lib/libc.so.6
Alexander> #1 0x00007ffff6e2a63b in () at /usr/lib/libxcb.so.1
Alexander> #2 0x00007ffff6e2c08f in () at /usr/lib/libxcb.so.1
Alexander> #3 0x00007ffff6e2c203 in xcb_wait_for_reply64 () at /usr/lib/libxcb.so.1
Alexander> #4 0x00007ffff6e904b9 in _XReply () at /usr/lib/libX11.so.6
Alexander> #5 0x00007ffff6e71e71 in () at /usr/lib/libX11.so.6
Alexander> #6 0x00007ffff6e7254e in XLoadQueryFont () at /usr/lib/libX11.so.6
Alexander> #7 0x0000555555a8d875 in xfont_supported_scripts
Alexander> (display=0x555556594940, fontname=0x55556a79e428 "-misc-trirong
Alexander> medium-medium-i-normal--0-0-0-0-p-0-iso10646-1",
Alexander> props=XIL(0x7ffff27926e5), encoding=0x7ffff23ab8d0)
Alexander> at xfont.c:266

So this is the 'x' font backend, rather than the 'ftcr' font
backend, which I would not expect emacs to be falling back to. Do you
have any face/fontset customisations? Could you show them to us? (Iʼm
hoping youʼre not messing with the font-backend frame parameter anywhere)

Robert

[Robert Pluim]

>>>>> On Thu, 3 Sep 2020 11:53:05 +0200, Alexander Shukaev <em...@Alexander.Shukaev.name> said:

Alexander> On 03/09/2020 11:50, Alexander Shukaev wrote:
>> On 03/09/2020 11:40, Alexander Shukaev wrote:
>>> (gdb) f 7
>>> #7  0x0000555555a8d875 in xfont_supported_scripts
>>> (display=0x555556594940, fontname=0x55556a79e428 "-misc-trirong
>>> medium-medium-i-normal--0-0-0-0-p-0-iso10646-1",
>>> props=XIL(0x7ffff27926e5),
>>>      encoding=0x7ffff23ab8d0) at xfont.c:266
>>> 266          xfont = XLoadQueryFont (display, fontname);
>>> (gdb) pp fontname
>>> #<INVALID_LISP_OBJECT 0x55556a79e428>
>>> (gdb) pp fontname
>>> #<INVALID_LISP_OBJECT 0x55556a79e428>
>>> (gdb) p fontname
>>> $3 = 0x55556a79e428 "-misc-trirong
>>> medium-medium-i-normal--0-0-0-0-p-0-iso10646-1"
>>> (gdb)
>> It appears to always be different `fontname' here as I try multiple
>> times to reproduce.  Maybe it's not really hanging but is merely
>> ultra-slow somehow in looping over the fonts here.  Any ideas?

Alexander> Hmm, right, waited for about a minute or so, and the file got opened
Alexander> finally. Reopening it was instant as well as if something got
Alexander> cached/loaded already. So any ideas how to speed things up here? I
Alexander> don't think I've encountered that with 26.3...

You can check easily enough by building emacs-27 --without-cairo, that
should get you back to emacs-26's font handling.

The issue is: why is Emacs falling back to the 'x' backend?

Robert

[Alexander Shukaev]

The only related font configurations that I can think of are the following:

(defcustom init-font-families
'("Powerline Consolas"
"Consolas for Powerline"
"Consolas"
;;
"Powerline Inconsolata-g"
"Inconsolata-g for Powerline"
"Inconsolata-g"
;;
"Powerline Source Code Pro"
"Source Code Pro for Powerline"
"Source Code Pro"
;;
"Powerline DejaVu Sans Mono"
"DejaVu Sans Mono for Powerline"
"DejaVu Sans Mono"
;;
"Monospace")
"List of font families."
:group 'init
:type 'list)

(defcustom init-font-size
12
"Size of font."
:group 'init
:type 'integer)

(defun init-frame-font-setup
(&optional frame)
(unless frame (setq frame (selected-frame)))
(with-selected-frame frame
(when (and (not noninteractive) (init-display-graphic-p))
(let ((font (assoc 'font default-frame-alist)))
(if font
(when (eq frame frame-initial-frame)
(set-frame-font font t t)
(unless noninteractive
(message "Font: `%s'" font)))
(let ((font-family (catch 'break
(dolist (font-family init-font-families)
(when (member font-family
(font-family-list))
(throw 'break font-family))))))
(setq font (when font-family
(format "%s-%d" font-family init-font-size))))
(when font
(add-to-list 'default-frame-alist `(font . ,font))
(set-frame-font font t t)
(unless noninteractive
(message "Font: `%s'" font))))))))

(unless (or noninteractive (daemonp))
(when (init-display-graphic-p)
(init-frame-font-setup)))

(dolist (hook '(after-make-frame-functions
focus-in-hook))
(add-hook hook #'init-frame-font-setup))

With what I consistently get output

Font: ‘Consolas-12’

for several years already on various Linux systems that I'm using so far.

[Robert Pluim]

>>>>> On Thu, 3 Sep 2020 12:24:30 +0200, Alexander Shukaev <em...@Alexander.Shukaev.name> said:

Alexander> The only related font configurations that I can think of are the following:

Alexander> With what I consistently get output

Alexander> Font: ‘Consolas-12’

Alexander> for several years already on various Linux systems that I'm using so far.

OK. Is this happening on particular files? Is it possible they have
esoteric Unicode characters in them?

One other thing: do you have Symbola installed? Thatʼs the default
fallback font Emacs uses for symbols, if itʼs not found it needs to
search harder.

Robert

[Alexander Shukaev]

That file is indeed special because it has some Unicode:

ꪯ鵞

Symbola was there, though outdated, I just updated it. Not sure if it's
related, but now that file loads somewhat faster, under 10 seconds roughly.

[Robert Pluim]

>>>>> On Thu, 3 Sep 2020 14:28:58 +0200, Alexander Shukaev <em...@Alexander.Shukaev.name> said:

Alexander> On 03/09/2020 14:13, Robert Pluim wrote:
>>>>>>> On Thu, 3 Sep 2020 12:24:30 +0200, Alexander Shukaev <em...@Alexander.Shukaev.name> said:
Alexander> The only related font configurations that I can
>> think of are the following:
Alexander> With what I consistently get output
Alexander> Font: ‘Consolas-12’
Alexander> for several years already on various Linux systems
>> that I'm using so far.
>> OK. Is this happening on particular files? Is it possible they have
>> esoteric Unicode characters in them?
>> One other thing: do you have Symbola installed? Thatʼs the default
>> fallback font Emacs uses for symbols, if itʼs not found it needs to
>> search harder.
>> Robert
>>

Alexander> That file is indeed special because it has some Unicode:

Alexander> ꪯ鵞

tai-viet and han scripts. My GNU/Linux build uses 'Noto Sans Tai Viet'
for the one, and 'Noto Sans CJK KR' for the other (both via the ftcr
backend), and thereʼs no slowdown. (you can use C-u C-x = to check).

Alexander> Symbola was there, though outdated, I just updated it. Not sure if
Alexander> it's related, but now that file loads somewhat faster, under 10
Alexander> seconds roughly.

I guess that depends if you have characters in there that are covered
by Symbola.

Robert

[Andreas Schwab]

On Sep 03 2020, Robert Pluim wrote:

> tai-viet and han scripts. My GNU/Linux build uses 'Noto Sans Tai Viet'
> for the one, and 'Noto Sans CJK KR' for the other (both via the ftcr
> backend), and thereʼs no slowdown. (you can use C-u C-x = to check).

Do you have many fonts installed?

Andreas.

--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."

[Robert Pluim]

>>>>> On Thu, 03 Sep 2020 14:52:22 +0200, Andreas Schwab <sch...@linux-m68k.org> said:

Andreas> On Sep 03 2020, Robert Pluim wrote:
>> tai-viet and han scripts. My GNU/Linux build uses 'Noto Sans Tai Viet'
>> for the one, and 'Noto Sans CJK KR' for the other (both via the ftcr
>> backend), and thereʼs no slowdown. (you can use C-u C-x = to check).

Andreas> Do you have many fonts installed?

fc-list | wc -l
2897

Is that a lot? I donʼt know; at some point I went through and made
sure I had all the fonts required to display etc/HELLO, which included
finding ones for Tai Viet.

Robert

[Eli Zaretskii]

> From: Robert Pluim <rpl...@gmail.com>
> Date: Thu, 03 Sep 2020 11:58:50 +0200
> Cc: 43...@debbugs.gnu.org

>
> So this is the 'x' font backend, rather than the 'ftcr' font
> backend, which I would not expect emacs to be falling back to.

Why do you think this is evidence of using the fallback backend?
AFAIR, when Emacs needs to find a font for a character, it loops over
all the fonts with all the available backends, and only later decides
which of the fonts to use. Don't you see that if you type some
character unlikely to have been seen in an "emacs -Q" session?

[Andreas Schwab]

On Sep 03 2020, Robert Pluim wrote:

>>>>>> On Thu, 03 Sep 2020 14:52:22 +0200, Andreas Schwab <sch...@linux-m68k.org> said:
>
> Andreas> On Sep 03 2020, Robert Pluim wrote:
> >> tai-viet and han scripts. My GNU/Linux build uses 'Noto Sans Tai Viet'
> >> for the one, and 'Noto Sans CJK KR' for the other (both via the ftcr
> >> backend), and thereʼs no slowdown. (you can use C-u C-x = to check).
>
> Andreas> Do you have many fonts installed?
>
> fc-list | wc -l
> 2897

$ fc-list | wc -l
11168

And there is a huge slowdown here.

[Robert Pluim]

>>>>> On Thu, 03 Sep 2020 16:19:56 +0300, Eli Zaretskii <el...@gnu.org> said:

>> From: Robert Pluim <rpl...@gmail.com>
>> Date: Thu, 03 Sep 2020 11:58:50 +0200
>> Cc: 43...@debbugs.gnu.org
>>
>> So this is the 'x' font backend, rather than the 'ftcr' font
>> backend, which I would not expect emacs to be falling back to.

Eli> Why do you think this is evidence of using the fallback backend?
Eli> AFAIR, when Emacs needs to find a font for a character, it loops over
Eli> all the fonts with all the available backends, and only later decides
Eli> which of the fonts to use. Don't you see that if you type some
Eli> character unlikely to have been seen in an "emacs -Q" session?

Youʼre right, Iʼd run through this in gdb, and set my breakpoint on
the wrong function.

'C-u C-x =' would tell us which backend ended up being used.

Robert

[Robert Pluim]

>>>>> On Thu, 03 Sep 2020 15:28:45 +0200, Andreas Schwab <sch...@linux-m68k.org> said:

Andreas> On Sep 03 2020, Robert Pluim wrote:
>>>>>>> On Thu, 03 Sep 2020 14:52:22 +0200, Andreas Schwab <sch...@linux-m68k.org> said:
>>
Andreas> On Sep 03 2020, Robert Pluim wrote:
>> >> tai-viet and han scripts. My GNU/Linux build uses 'Noto Sans Tai Viet'
>> >> for the one, and 'Noto Sans CJK KR' for the other (both via the ftcr
>> >> backend), and thereʼs no slowdown. (you can use C-u C-x = to check).
>>
Andreas> Do you have many fonts installed?
>>
>> fc-list | wc -l
>> 2897

Andreas> $ fc-list | wc -l
Andreas> 11168

Andreas> And there is a huge slowdown here.

Does it go away if you set font-backend . ftcrhb in your frame
parameters (assuming youʼre using Cairo)?

Robert

[Andreas Schwab]

On Sep 03 2020, Robert Pluim wrote:

> Does it go away if you set font-backend . ftcrhb in your frame
> parameters (assuming youʼre using Cairo)?

That completely removes the delay.

[Robert Pluim]

>>>>> On Thu, 03 Sep 2020 16:48:04 +0200, Andreas Schwab <sch...@linux-m68k.org> said:

Andreas> On Sep 03 2020, Robert Pluim wrote:
>> Does it go away if you set font-backend . ftcrhb in your frame
>> parameters (assuming youʼre using Cairo)?

Andreas> That completely removes the delay.

So the solution is easy: just deprecate and remove the 'x' backend :-)

Robert

[Alexander Shukaev]

Love that tip, man! Confirming the speed up. Thanks a lot!

[Eli Zaretskii]

> From: Robert Pluim <rpl...@gmail.com>
> Date: Thu, 03 Sep 2020 17:10:30 +0200
> Cc: 43...@debbugs.gnu.org, Alexander Shukaev <em...@Alexander.Shukaev.name>

>
> >>>>> On Thu, 03 Sep 2020 16:48:04 +0200, Andreas Schwab <sch...@linux-m68k.org> said:
>
> Andreas> On Sep 03 2020, Robert Pluim wrote:
> >> Does it go away if you set font-backend . ftcrhb in your frame
> >> parameters (assuming youʼre using Cairo)?
>
> Andreas> That completely removes the delay.
>
> So the solution is easy: just deprecate and remove the 'x' backend :-)

Easy: yes. Possible: no. Unfortunately.

Do we understand why including the x backend produces such a huge
delay? Where is most of that time spent, and why?

[Andreas Schwab]

On Sep 03 2020, Eli Zaretskii wrote:

> Do we understand why including the x backend produces such a huge
> delay? Where is most of that time spent, and why?

My guess would be that probing fonts via the x backend is expensive due
to round trips to the X server (and the X server is quite busy during
that time).

[Eli Zaretskii]

> From: Andreas Schwab <sch...@linux-m68k.org>
> Cc: Robert Pluim <rpl...@gmail.com>, 43...@debbugs.gnu.org,
> em...@Alexander.Shukaev.name
> Date: Thu, 03 Sep 2020 19:51:17 +0200

>
> On Sep 03 2020, Eli Zaretskii wrote:
>
> > Do we understand why including the x backend produces such a huge
> > delay? Where is most of that time spent, and why?
>
> My guess would be that probing fonts via the x backend is expensive due
> to round trips to the X server (and the X server is quite busy during
> that time).

If that is the reason, I guess we should try to minimize the number of
fonts for which this is done. Like, for example, set up some data
structure to be consulted when a deciding whether a given font should
be used with the x backend. After all, the number of fonts for which
that backend is needed is quite small, basically bitmapped fonts.