* bug#37786: 26.3; Emacs crashes when calling function to decode string
@ 2019-10-17 4:11 Allen Li
2019-10-17 4:22 ` Lars Ingebrigtsen
0 siblings, 1 reply; 15+ messages in thread
From: Allen Li @ 2019-10-17 4:11 UTC (permalink / raw)
To: 37786
The following expression, when evaluated in emacs -Q, causes emacs to
crash and dump core:
(mail-decode-encoded-word-string #("=?UTF-8?B?4pyoUERYQ09OIFNBTEXinKggRW5qb3kgU3BlY2lhbCBPZmZlcnMg?= =?UTF-8?B?V2hpbGUgWW91IFdhaXQh?=" 0 64 (ws-butler-chg chg) 64 65 (ws-butler-chg chg) 65 97 (ws-butler-chg chg)))
In GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
of 2019-08-29 built on juergen
Windowing system distributor 'The X.Org Foundation', version 11.0.12005000
System Description: Arch Linux
Configured using:
'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
--localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules
'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt'
CPPFLAGS=-D_FORTIFY_SOURCE=2
LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'
Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD LCMS2
Important settings:
value of $LANG: en_US.UTF-8
locale-coding-system: utf-8-unix
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37786: 26.3; Emacs crashes when calling function to decode string
2019-10-17 4:11 bug#37786: 26.3; Emacs crashes when calling function to decode string Allen Li
@ 2019-10-17 4:22 ` Lars Ingebrigtsen
2019-10-17 9:53 ` Robert Pluim
0 siblings, 1 reply; 15+ messages in thread
From: Lars Ingebrigtsen @ 2019-10-17 4:22 UTC (permalink / raw)
To: Allen Li; +Cc: 37786
Allen Li <darkfeline@felesatra.moe> writes:
> The following expression, when evaluated in emacs -Q, causes emacs to
> crash and dump core:
>
> (mail-decode-encoded-word-string #("=?UTF-8?B?4pyoUERYQ09OIFNBTEXinKggRW5qb3kgU3BlY2lhbCBPZmZlcnMg?= =?UTF-8?B?V2hpbGUgWW91IFdhaXQh?=" 0 64 (ws-butler-chg chg) 64 65 (ws-butler-chg chg) 65 97 (ws-butler-chg chg)))
I'm unable to reproduce this in Emacs 27 or Emacs 26.3.
Could you do this under gdb and post the backtrace?
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37786: 26.3; Emacs crashes when calling function to decode string
2019-10-17 4:22 ` Lars Ingebrigtsen
@ 2019-10-17 9:53 ` Robert Pluim
2019-10-18 4:28 ` Allen Li
0 siblings, 1 reply; 15+ messages in thread
From: Robert Pluim @ 2019-10-17 9:53 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37786, Allen Li
>>>>> On Thu, 17 Oct 2019 06:22:10 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:
Lars> Allen Li <darkfeline@felesatra.moe> writes:
>> The following expression, when evaluated in emacs -Q, causes emacs to
>> crash and dump core:
>>
>> (mail-decode-encoded-word-string
>> #("=?UTF-8?B?4pyoUERYQ09OIFNBTEXinKggRW5qb3kgU3BlY2lhbCBPZmZlcnMg?=
>> =?UTF-8?B?V2hpbGUgWW91IFdhaXQh?=" 0 64 (ws-butler-chg chg) 64 65
>> (ws-butler-chg chg) 65 97 (ws-butler-chg chg)))
Lars> I'm unable to reproduce this in Emacs 27 or Emacs 26.3.
Lars> Could you do this under gdb and post the backtrace?
Probably font-related. I suspect "C-x 8 RET 2728" will cause the same
crash for OP.
Robert
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37786: 26.3; Emacs crashes when calling function to decode string
2019-10-17 9:53 ` Robert Pluim
@ 2019-10-18 4:28 ` Allen Li
2019-10-18 9:49 ` Robert Pluim
0 siblings, 1 reply; 15+ messages in thread
From: Allen Li @ 2019-10-18 4:28 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: 37786
Robert Pluim <rpluim@gmail.com> writes:
>>>>>> On Thu, 17 Oct 2019 06:22:10 +0200, Lars Ingebrigtsen <larsi@gnus.org> said:
>
> Lars> Allen Li <darkfeline@felesatra.moe> writes:
> >> The following expression, when evaluated in emacs -Q, causes emacs to
> >> crash and dump core:
> >>
> >> (mail-decode-encoded-word-string
> >> #("=?UTF-8?B?4pyoUERYQ09OIFNBTEXinKggRW5qb3kgU3BlY2lhbCBPZmZlcnMg?=
> >> =?UTF-8?B?V2hpbGUgWW91IFdhaXQh?=" 0 64 (ws-butler-chg chg) 64 65
> >> (ws-butler-chg chg) 65 97 (ws-butler-chg chg)))
>
> Lars> I'm unable to reproduce this in Emacs 27 or Emacs 26.3.
>
> Lars> Could you do this under gdb and post the backtrace?
This is the backtrace using the simpler repro from Robert.
#0 0x0000000000565ae9 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:363
#1 0x000000000058ca83 in emacs_abort () at sysdep.c:2380
#2 0x000000000045c17e in redisplay_internal () at xdisp.c:13797
#3 0x000000000045e0b7 in redisplay_preserve_echo_area (from_where=13) at xdisp.c:14602
#4 0x0000000000667fbe in Fdelete_process (process=XIL(0x6aa3395)) at process.c:1054
#5 0x000000000067716b in kill_buffer_processes (buffer=XIL(0)) at process.c:7819
#6 0x00000000005683d0 in shut_down_emacs (sig=0, stuff=XIL(0)) at emacs.c:2096
#7 0x000000000052d854 in x_connection_closed (dpy=0x2b77f50, error_message=0x7fffffff6fc0 "X protocol error: BadLength (poly request too large or internal Xlib length error) on protocol request 139", ioerror=false) at xterm.c:9799
#8 0x000000000052da1b in x_error_quitter (display=0x2b77f50, event=0x7fffffff7160) at xterm.c:9893
#9 0x000000000052d966 in x_error_handler (display=0x2b77f50, event=0x7fffffff7160) at xterm.c:9863
#10 0x00007ffff6ce75db in _XError () at /usr/lib/libX11.so.6
#11 0x00007ffff6ce4388 in () at /usr/lib/libX11.so.6
#12 0x00007ffff6ce4425 in () at /usr/lib/libX11.so.6
#13 0x00007ffff6ce4d8a in _XEventsQueued () at /usr/lib/libX11.so.6
#14 0x00007ffff6cd6782 in XPending () at /usr/lib/libX11.so.6
#15 0x00007ffff7671a00 in () at /usr/lib/libgdk-3.so.0
#16 0x00007ffff6e79a60 in g_main_context_prepare () at /usr/lib/libglib-2.0.so.0
#17 0x00007ffff6e7a0a6 in () at /usr/lib/libglib-2.0.so.0
#18 0x00007ffff6e7a2fa in g_main_context_pending () at /usr/lib/libglib-2.0.so.0
#19 0x00007ffff79ae550 in gtk_events_pending () at /usr/lib/libgtk-3.so.0
#20 0x000000000052c185 in XTread_socket (terminal=0x1232e40 <bss_sbrk_buffer+7610880>, hold_quit=0x7fffffff74a0) at xterm.c:9120
#21 0x000000000057685f in gobble_input () at keyboard.c:6909
#22 0x0000000000576da8 in handle_async_input () at keyboard.c:7146
#23 0x0000000000576dc7 in process_pending_signals () at keyboard.c:7160
#24 0x0000000000576e07 in unblock_input_to (level=0) at keyboard.c:7175
#25 0x0000000000576e2b in unblock_input () at keyboard.c:7194
#26 0x00000000006ab340 in xftfont_open (f=0x1279c30 <bss_sbrk_buffer+7901168>, entity=XIL(0x5f805b5), pixel_size=15) at xftfont.c:391
#27 0x000000000063107b in font_open_entity (f=0x1279c30 <bss_sbrk_buffer+7901168>, entity=XIL(0x5f805b5), pixel_size=15) at font.c:2903
#28 0x0000000000632a50 in font_open_for_lface (f=0x1279c30 <bss_sbrk_buffer+7901168>, entity=XIL(0x5f805b5), attrs=0x32610d0, spec=XIL(0)) at font.c:3332
#29 0x00000000006aea8a in fontset_find_font (fontset=XIL(0x1470c35), c=10024, face=0x32610d0, charset_id=-1, fallback=true) at fontset.c:707
#30 0x00000000006aefb7 in fontset_font (fontset=XIL(0x1470c35), c=10024, face=0x32610d0, id=-1) at fontset.c:788
#31 0x00000000006af6bc in face_for_char (f=0x1279c30 <bss_sbrk_buffer+7901168>, face=0x32610d0, c=10024, pos=1, object=XIL(0)) at fontset.c:990
#32 0x0000000000563994 in FACE_FOR_CHAR (f=0x1279c30 <bss_sbrk_buffer+7901168>, face=0x32610d0, character=10024, pos=1, object=XIL(0)) at dispextern.h:1818
#33 0x000000000044b256 in get_next_display_element (it=0x7fffffff8ef0) at xdisp.c:7288
#34 0x00000000004730c0 in display_line (it=0x7fffffff8ef0, cursor_vpos=0) at xdisp.c:21337
#35 0x0000000000467f0f in try_window (window=XIL(0x127ac35), pos=..., flags=1) at xdisp.c:17592
#36 0x0000000000465a0d in redisplay_window (window=XIL(0x127ac35), just_this_one_p=false) at xdisp.c:17039
#37 0x000000000045e869 in redisplay_window_0 (window=XIL(0x127ac35)) at xdisp.c:14799
#38 0x000000000061316d in internal_condition_case_1 (bfun=0x45e827 <redisplay_window_0>, arg=XIL(0x127ac35), handlers=XIL(0xb5afb3), hfun=0x45e7ef <redisplay_window_error>) at eval.c:1356
#39 0x000000000045e7c3 in redisplay_windows (window=XIL(0x127ac35)) at xdisp.c:14779
#40 0x000000000045d608 in redisplay_internal () at xdisp.c:14268
#41 0x000000000045b4ee in redisplay () at xdisp.c:13488
#42 0x000000000056db90 in read_char (commandflag=1, map=XIL(0x6564303), prev_event=XIL(0), used_mouse_menu=0x7fffffffe1f1, end_time=0x0) at keyboard.c:2480
#43 0x000000000057b533 in read_key_sequence (keybuf=0x7fffffffe390, bufsize=30, prompt=XIL(0), dont_downcase_last=false, can_return_switch_frame=true, fix_current_buffer=true, prevent_redisplay=false) at keyboard.c:9147
#44 0x000000000056adfb in command_loop_1 () at keyboard.c:1368
#45 0x00000000006130c6 in internal_condition_case (bfun=0x56a9cf <command_loop_1>, handlers=XIL(0x5220), hfun=0x56a17a <cmd_error>) at eval.c:1332
#46 0x000000000056a6b0 in command_loop_2 (ignore=XIL(0)) at keyboard.c:1110
#47 0x0000000000612963 in internal_catch (tag=XIL(0xc6c0), func=0x56a683 <command_loop_2>, arg=XIL(0)) at eval.c:1097
#48 0x000000000056a64e in command_loop () at keyboard.c:1089
#49 0x0000000000569d4b in recursive_edit_1 () at keyboard.c:695
#50 0x0000000000569ecc in Frecursive_edit () at keyboard.c:766
#51 0x00000000005679ae in main (argc=1, argv=0x7fffffffe7f8) at emacs.c:1713
>
> Probably font-related. I suspect "C-x 8 RET 2728" will cause the same
> crash for OP.
>
> Robert
Yep, this also crashes for me.
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37786: 26.3; Emacs crashes when calling function to decode string
2019-10-18 4:28 ` Allen Li
@ 2019-10-18 9:49 ` Robert Pluim
2019-10-19 1:18 ` Allen Li
0 siblings, 1 reply; 15+ messages in thread
From: Robert Pluim @ 2019-10-18 9:49 UTC (permalink / raw)
To: Allen Li; +Cc: Lars Ingebrigtsen, 37786
>>>>> On Thu, 17 Oct 2019 21:28:35 -0700, Allen Li <darkfeline@felesatra.moe> said:
Allen> This is the backtrace using the simpler repro from Robert.
Allen> #0 0x0000000000565ae9 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:363
Allen> #1 0x000000000058ca83 in emacs_abort () at sysdep.c:2380
Allen> #2 0x000000000045c17e in redisplay_internal () at xdisp.c:13797
Allen> #3 0x000000000045e0b7 in redisplay_preserve_echo_area (from_where=13) at xdisp.c:14602
Allen> #4 0x0000000000667fbe in Fdelete_process (process=XIL(0x6aa3395)) at process.c:1054
Allen> #5 0x000000000067716b in kill_buffer_processes (buffer=XIL(0)) at process.c:7819
Allen> #6 0x00000000005683d0 in shut_down_emacs (sig=0, stuff=XIL(0)) at emacs.c:2096
Allen> #7 0x000000000052d854 in x_connection_closed (dpy=0x2b77f50,
Allen> error_message=0x7fffffff6fc0 "X protocol error: BadLength (poly
Allen> request too large or internal Xlib length error) on protocol request
Allen> 139", ioerror=false) at xterm.c:9799
I thought weʼd fixed these kinds of bugs, but obviously not. Can you
try your test in combination with the following from etc/DEBUG, it
should tell us which font is responsible:
For X protocol errors related to displaying unusual characters or to
font-related customizations, try invoking Emacs like this:
XFT_DEBUG=16 emacs -xrm "emacs.synchronous: true"
This should produce information from the libXft library which could
give useful hints regarding font-related problems in that library.
Regards
Robert
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37786: 26.3; Emacs crashes when calling function to decode string
2019-10-18 9:49 ` Robert Pluim
@ 2019-10-19 1:18 ` Allen Li
2019-10-21 10:02 ` Robert Pluim
0 siblings, 1 reply; 15+ messages in thread
From: Allen Li @ 2019-10-19 1:18 UTC (permalink / raw)
To: Robert Pluim; +Cc: 37786
Robert Pluim <rpluim@gmail.com> writes:
>>>>>> On Thu, 17 Oct 2019 21:28:35 -0700, Allen Li <darkfeline@felesatra.moe> said:
>
> Allen> This is the backtrace using the simpler repro from Robert.
>
> Allen> #0 0x0000000000565ae9 in terminate_due_to_signal (sig=6, backtrace_limit=40) at emacs.c:363
> Allen> #1 0x000000000058ca83 in emacs_abort () at sysdep.c:2380
> Allen> #2 0x000000000045c17e in redisplay_internal () at xdisp.c:13797
> Allen> #3 0x000000000045e0b7 in redisplay_preserve_echo_area (from_where=13) at xdisp.c:14602
> Allen> #4 0x0000000000667fbe in Fdelete_process (process=XIL(0x6aa3395)) at process.c:1054
> Allen> #5 0x000000000067716b in kill_buffer_processes (buffer=XIL(0)) at process.c:7819
> Allen> #6 0x00000000005683d0 in shut_down_emacs (sig=0, stuff=XIL(0)) at emacs.c:2096
> Allen> #7 0x000000000052d854 in x_connection_closed (dpy=0x2b77f50,
> Allen> error_message=0x7fffffff6fc0 "X protocol error: BadLength (poly
> Allen> request too large or internal Xlib length error) on protocol request
> Allen> 139", ioerror=false) at xterm.c:9799
>
> I thought weʼd fixed these kinds of bugs, but obviously not. Can you
> try your test in combination with the following from etc/DEBUG, it
> should tell us which font is responsible:
>
> For X protocol errors related to displaying unusual characters or to
> font-related customizations, try invoking Emacs like this:
>
> XFT_DEBUG=16 emacs -xrm "emacs.synchronous: true"
>
> This should produce information from the libXft library which could
> give useful hints regarding font-related problems in that library.
That gives me the following output:
Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-It.otf/0 matches new
Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-It.otf/0
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0 matches new
Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0 matches new
Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 matches existing (2)
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0 matches existing (2)
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0 matches existing (2)
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 matches existing (3)
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0 matches existing (3)
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0 matches existing (3)
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 matches existing (4)
FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 matches existing (4)
FontFile /usr/share/fonts/noto/NotoColorEmoji.ttf/0 matches new
Loading file /usr/share/fonts/noto/NotoColorEmoji.ttf/0
and then Emacs hangs at this point.
>
> Regards
>
> Robert
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37786: 26.3; Emacs crashes when calling function to decode string
2019-10-19 1:18 ` Allen Li
@ 2019-10-21 10:02 ` Robert Pluim
2019-10-22 3:44 ` Allen Li
0 siblings, 1 reply; 15+ messages in thread
From: Robert Pluim @ 2019-10-21 10:02 UTC (permalink / raw)
To: Allen Li; +Cc: 37786
>>>>> On Fri, 18 Oct 2019 18:18:34 -0700, Allen Li <darkfeline@felesatra.moe> said:
Allen> That gives me the following output:
Allen> Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0
Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-It.otf/0 matches new
Allen> Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-It.otf/0
Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0 matches new
Allen> Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0
Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0 matches new
Allen> Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0
Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 matches existing (2)
Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0 matches existing (2)
Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0 matches existing (2)
Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 matches existing (3)
Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0 matches existing (3)
Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0 matches existing (3)
Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 matches existing (4)
Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 matches existing (4)
Allen> FontFile /usr/share/fonts/noto/NotoColorEmoji.ttf/0 matches new
Allen> Loading file /usr/share/fonts/noto/NotoColorEmoji.ttf/0
Allen> and then Emacs hangs at this point.
Hmm, that configuration of emacs should not be loading NotoColorEmoji
(unless you've somehow arranged for xft-ignore-color-fonts to be
nil). What's your version of fontconfig (probably from
/usr/include/fontconfig/fontconfig.h)?
(note that building emacs-27 with cairo enabled should solve this:
that doesnʼt use XFT).
Robert
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37786: 26.3; Emacs crashes when calling function to decode string
2019-10-21 10:02 ` Robert Pluim
@ 2019-10-22 3:44 ` Allen Li
2019-10-22 8:18 ` Robert Pluim
0 siblings, 1 reply; 15+ messages in thread
From: Allen Li @ 2019-10-22 3:44 UTC (permalink / raw)
To: 37786
Robert Pluim <rpluim@gmail.com> writes:
>>>>>> On Fri, 18 Oct 2019 18:18:34 -0700, Allen Li <darkfeline@felesatra.moe> said:
> Allen> That gives me the following output:
>
> Allen> Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0
> Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-It.otf/0 matches new
> Allen> Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-It.otf/0
> Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0 matches new
> Allen> Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0
> Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0 matches new
> Allen> Loading file /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0
> Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 matches existing (2)
> Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0 matches existing (2)
> Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0 matches existing (2)
> Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 matches existing (3)
> Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Light.otf/0 matches existing (3)
> Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Bold.otf/0 matches existing (3)
> Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 matches existing (4)
> Allen> FontFile /usr/share/fonts/adobe-source-code-pro/SourceCodePro-Regular.otf/0 matches existing (4)
> Allen> FontFile /usr/share/fonts/noto/NotoColorEmoji.ttf/0 matches new
> Allen> Loading file /usr/share/fonts/noto/NotoColorEmoji.ttf/0
>
> Allen> and then Emacs hangs at this point.
>
> Hmm, that configuration of emacs should not be loading NotoColorEmoji
> (unless you've somehow arranged for xft-ignore-color-fonts to be
> nil). What's your version of fontconfig (probably from
> /usr/include/fontconfig/fontconfig.h)?
I haven't touched xft-ignore-color-fonts (and it reproduces from emacs -Q)
#define FC_MAJOR 2
#define FC_MINOR 13
#define FC_REVISION 91
>
> (note that building emacs-27 with cairo enabled should solve this:
> that doesnʼt use XFT).
>
> Robert
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37786: 26.3; Emacs crashes when calling function to decode string
2019-10-22 3:44 ` Allen Li
@ 2019-10-22 8:18 ` Robert Pluim
2019-10-23 3:25 ` Allen Li
0 siblings, 1 reply; 15+ messages in thread
From: Robert Pluim @ 2019-10-22 8:18 UTC (permalink / raw)
To: Allen Li; +Cc: 37786
>>>>> On Mon, 21 Oct 2019 20:44:09 -0700, Allen Li <darkfeline@felesatra.moe> said:
>> Hmm, that configuration of emacs should not be loading NotoColorEmoji
>> (unless you've somehow arranged for xft-ignore-color-fonts to be
>> nil). What's your version of fontconfig (probably from
>> /usr/include/fontconfig/fontconfig.h)?
Allen> I haven't touched xft-ignore-color-fonts (and it reproduces from emacs -Q)
Allen> #define FC_MAJOR 2
Allen> #define FC_MINOR 13
Allen> #define FC_REVISION 91
Now Iʼm definitely confused. Which distribution/version of GNU/Linux is this?
Robert
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37786: 26.3; Emacs crashes when calling function to decode string
2019-10-22 8:18 ` Robert Pluim
@ 2019-10-23 3:25 ` Allen Li
2019-10-25 16:32 ` Robert Pluim
0 siblings, 1 reply; 15+ messages in thread
From: Allen Li @ 2019-10-23 3:25 UTC (permalink / raw)
To: 37786
Robert Pluim <rpluim@gmail.com> writes:
>>>>>> On Mon, 21 Oct 2019 20:44:09 -0700, Allen Li <darkfeline@felesatra.moe> said:
>
> >> Hmm, that configuration of emacs should not be loading NotoColorEmoji
> >> (unless you've somehow arranged for xft-ignore-color-fonts to be
> >> nil). What's your version of fontconfig (probably from
> >> /usr/include/fontconfig/fontconfig.h)?
>
> Allen> I haven't touched xft-ignore-color-fonts (and it reproduces from emacs -Q)
>
> Allen> #define FC_MAJOR 2
> Allen> #define FC_MINOR 13
> Allen> #define FC_REVISION 91
>
> Now Iʼm definitely confused. Which distribution/version of GNU/Linux is this?
Arch Linux
>
> Robert
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37786: 26.3; Emacs crashes when calling function to decode string
2019-10-23 3:25 ` Allen Li
@ 2019-10-25 16:32 ` Robert Pluim
2019-10-26 9:44 ` Allen Li
0 siblings, 1 reply; 15+ messages in thread
From: Robert Pluim @ 2019-10-25 16:32 UTC (permalink / raw)
To: Allen Li; +Cc: 37786
>>>>> On Tue, 22 Oct 2019 20:25:40 -0700, Allen Li <darkfeline@felesatra.moe> said:
Allen> I haven't touched xft-ignore-color-fonts (and it reproduces from emacs -Q)
>>
Allen> #define FC_MAJOR 2
Allen> #define FC_MINOR 13
Allen> #define FC_REVISION 91
>>
Thatʼs a very recent (and maybe even unreleased) version of
fontconfig.
Allen> Arch Linux
Hmm. Could you try the following against emacs-26 and see if it fixes
your crash? (the character will almost certainly end up displayed
wrong). This looks more like a fontconfig bug than anything else: the
pattern we've supplied to FcFontList explicitly says "donʼt give me
color fonts".
diff --git i/lisp/international/fontset.el w/lisp/international/fontset.el
index c90d4f53bd..e80a1a87b9 100644
--- i/lisp/international/fontset.el
+++ w/lisp/international/fontset.el
@@ -804,7 +804,6 @@ setup-default-fontset
#x2664
(#x2667 . #x2669)
(#x266C . #x26FF)
- (#x2700 . #x27bF) ;; Dingbats
(#x27C0 . #x27EF) ;; Misc Mathematical Symbols-A
(#x27F0 . #x27FF) ;; Supplemental Arrows-A
(#x2900 . #x297F) ;; Supplemental Arrows-B
diff --git i/src/ftfont.c w/src/ftfont.c
index 823fb2095c..017b349318 100644
--- i/src/ftfont.c
+++ w/src/ftfont.c
@@ -861,6 +861,9 @@ ftfont_list (struct frame *f, Lisp_Object spec)
#endif /* FC_CAPABILITY */
#ifdef FC_FONTFORMAT
FC_FONTFORMAT,
+#endif
+#ifdef FC_COLOR
+ FC_COLOR,
#endif
NULL);
if (! objset)
@@ -902,6 +905,15 @@ ftfont_list (struct frame *f, Lisp_Object spec)
{
Lisp_Object entity;
+ {
+ FcBool b;
+ if (FcPatternGetBool (fontset->fonts[i], FC_COLOR, 0, &b)
+ == FcResultMatch && b)
+ {
+ fprintf (stderr, "Skipping Color font\n");
+ continue;
+ }
+ }
if (spacing >= 0)
{
int this;
^ permalink raw reply related [flat|nested] 15+ messages in thread
* bug#37786: 26.3; Emacs crashes when calling function to decode string
2019-10-25 16:32 ` Robert Pluim
@ 2019-10-26 9:44 ` Allen Li
2019-10-27 8:26 ` Robert Pluim
0 siblings, 1 reply; 15+ messages in thread
From: Allen Li @ 2019-10-26 9:44 UTC (permalink / raw)
To: 37786
Robert Pluim <rpluim@gmail.com> writes:
>>>>>> On Tue, 22 Oct 2019 20:25:40 -0700, Allen Li <darkfeline@felesatra.moe> said:
>
> Allen> I haven't touched xft-ignore-color-fonts (and it reproduces from emacs -Q)
> >>
> Allen> #define FC_MAJOR 2
> Allen> #define FC_MINOR 13
> Allen> #define FC_REVISION 91
> >>
>
> Thatʼs a very recent (and maybe even unreleased) version of
> fontconfig.
>
> Allen> Arch Linux
>
> Hmm. Could you try the following against emacs-26 and see if it fixes
> your crash? (the character will almost certainly end up displayed
> wrong). This looks more like a fontconfig bug than anything else: the
> pattern we've supplied to FcFontList explicitly says "donʼt give me
> color fonts".
Yep, this fixes the crash and I get the box with unicode codepoint
inside. I don't know anything about fontconfig, so I can't comment on
whether this is a fontconfig bug.
>
> diff --git i/lisp/international/fontset.el w/lisp/international/fontset.el
> index c90d4f53bd..e80a1a87b9 100644
> --- i/lisp/international/fontset.el
> +++ w/lisp/international/fontset.el
> @@ -804,7 +804,6 @@ setup-default-fontset
> #x2664
> (#x2667 . #x2669)
> (#x266C . #x26FF)
> - (#x2700 . #x27bF) ;; Dingbats
> (#x27C0 . #x27EF) ;; Misc Mathematical Symbols-A
> (#x27F0 . #x27FF) ;; Supplemental Arrows-A
> (#x2900 . #x297F) ;; Supplemental Arrows-B
> diff --git i/src/ftfont.c w/src/ftfont.c
> index 823fb2095c..017b349318 100644
> --- i/src/ftfont.c
> +++ w/src/ftfont.c
> @@ -861,6 +861,9 @@ ftfont_list (struct frame *f, Lisp_Object spec)
> #endif /* FC_CAPABILITY */
> #ifdef FC_FONTFORMAT
> FC_FONTFORMAT,
> +#endif
> +#ifdef FC_COLOR
> + FC_COLOR,
> #endif
> NULL);
> if (! objset)
> @@ -902,6 +905,15 @@ ftfont_list (struct frame *f, Lisp_Object spec)
> {
> Lisp_Object entity;
>
> + {
> + FcBool b;
> + if (FcPatternGetBool (fontset->fonts[i], FC_COLOR, 0, &b)
> + == FcResultMatch && b)
> + {
> + fprintf (stderr, "Skipping Color font\n");
> + continue;
> + }
> + }
> if (spacing >= 0)
> {
> int this;
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37786: 26.3; Emacs crashes when calling function to decode string
2019-10-26 9:44 ` Allen Li
@ 2019-10-27 8:26 ` Robert Pluim
2019-11-05 17:40 ` Robert Pluim
0 siblings, 1 reply; 15+ messages in thread
From: Robert Pluim @ 2019-10-27 8:26 UTC (permalink / raw)
To: Allen Li; +Cc: 37786
>>>>> On Sat, 26 Oct 2019 02:44:52 -0700, Allen Li <darkfeline@felesatra.moe> said:
>> Hmm. Could you try the following against emacs-26 and see if it fixes
>> your crash? (the character will almost certainly end up displayed
>> wrong). This looks more like a fontconfig bug than anything else: the
>> pattern we've supplied to FcFontList explicitly says "donʼt give me
>> color fonts".
Allen> Yep, this fixes the crash and I get the box with unicode codepoint
Allen> inside. I don't know anything about fontconfig, so I can't comment on
Allen> whether this is a fontconfig bug.
Thanks for testing. Iʼll have to write a standalone test case against
fontconfig before I can say whether itʼs a fontconfig bug or not, in
the meantime Iʼll clean up the patch.
Regards
Robert
^ permalink raw reply [flat|nested] 15+ messages in thread
* bug#37786: 26.3; Emacs crashes when calling function to decode string
2019-10-27 8:26 ` Robert Pluim
@ 2019-11-05 17:40 ` Robert Pluim
2019-11-13 14:03 ` Robert Pluim
0 siblings, 1 reply; 15+ messages in thread
From: Robert Pluim @ 2019-11-05 17:40 UTC (permalink / raw)
To: Allen Li; +Cc: 37786
[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]
>>>>> On Sun, 27 Oct 2019 09:26:35 +0100, Robert Pluim <rpluim@gmail.com> said:
>>>>> On Sat, 26 Oct 2019 02:44:52 -0700, Allen Li <darkfeline@felesatra.moe> said:
>>> Hmm. Could you try the following against emacs-26 and see if it fixes
>>> your crash? (the character will almost certainly end up displayed
>>> wrong). This looks more like a fontconfig bug than anything else: the
>>> pattern we've supplied to FcFontList explicitly says "donʼt give me
>>> color fonts".
Allen> Yep, this fixes the crash and I get the box with unicode codepoint
Allen> inside. I don't know anything about fontconfig, so I can't comment on
Allen> whether this is a fontconfig bug.
Robert> Thanks for testing. Iʼll have to write a standalone test case against
Robert> fontconfig before I can say whether itʼs a fontconfig bug or not, in
Robert> the meantime Iʼll clean up the patch.
I think itʼs a fontconfig bug, but Iʼve received no response from the
fontconfig guys. Perhaps I need to use their new-fangled issue tracker
thing rather than good old email. In any case, both Arch and Fedora 31
have fontconfig packages with this issue, so we need to paper^Wfix the
issue our end.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Ignore-color-fonts-returned-from-FcFontList.patch --]
[-- Type: text/x-patch, Size: 1696 bytes --]
From aabd13bba282563410ef95764cad39f02ecb5d84 Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim@gmail.com>
Date: Mon, 4 Nov 2019 17:44:57 +0100
Subject: [PATCH] Ignore color fonts returned from FcFontList
To: emacs-devel@gnu.org
* src/ftfont.c (ftfont_list): [HAVE_XFT && FC_COLOR]: Ask FcFontList
to return FC_COLOR attribute. Check returned attribute for
non-FcFalse, since some color fonts have a color attribute that's
neither FcFalse nor FcTrue (Bug#37786).
---
src/ftfont.c | 17 ++++++++++++++++-
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/src/ftfont.c b/src/ftfont.c
index 77a4cf5de5..b066f55a18 100644
--- a/src/ftfont.c
+++ b/src/ftfont.c
@@ -864,6 +864,9 @@ ftfont_list (struct frame *f, Lisp_Object spec)
#endif /* FC_CAPABILITY */
#ifdef FC_FONTFORMAT
FC_FONTFORMAT,
+#endif
+#if defined HAVE_XFT && defined FC_COLOR
+ FC_COLOR,
#endif
NULL);
if (! objset)
@@ -904,7 +907,19 @@ ftfont_list (struct frame *f, Lisp_Object spec)
for (i = 0; i < fontset->nfont; i++)
{
Lisp_Object entity;
-
+#if defined HAVE_XFT && defined FC_COLOR
+ {
+ /* Some fonts, notably NotoColorEmoji, have an FC_COLOR value
+ that's neither FcTrue nor FcFalse, which means FcFontList
+ returns them even when it shouldn't really do so, so we
+ need to manually skip them here (Bug#37786). */
+ FcBool b;
+ if (Vxft_ignore_color_fonts
+ && FcPatternGetBool (fontset->fonts[i], FC_COLOR, 0, &b)
+ == FcResultMatch && b != FcFalse)
+ continue;
+ }
+#endif
if (spacing >= 0)
{
int this;
--
2.19.1.816.gcd69ec8cde
^ permalink raw reply related [flat|nested] 15+ messages in thread
* bug#37786: 26.3; Emacs crashes when calling function to decode string
2019-11-05 17:40 ` Robert Pluim
@ 2019-11-13 14:03 ` Robert Pluim
0 siblings, 0 replies; 15+ messages in thread
From: Robert Pluim @ 2019-11-13 14:03 UTC (permalink / raw)
To: Allen Li; +Cc: 37786
tags 37786 fixed
close 37786 27.1
quit
Fixed by adding "Noto Color Emoji" to face-ignored-fonts
instead. Closing.
Committed as eae50e88ef
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2019-11-13 14:03 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-17 4:11 bug#37786: 26.3; Emacs crashes when calling function to decode string Allen Li
2019-10-17 4:22 ` Lars Ingebrigtsen
2019-10-17 9:53 ` Robert Pluim
2019-10-18 4:28 ` Allen Li
2019-10-18 9:49 ` Robert Pluim
2019-10-19 1:18 ` Allen Li
2019-10-21 10:02 ` Robert Pluim
2019-10-22 3:44 ` Allen Li
2019-10-22 8:18 ` Robert Pluim
2019-10-23 3:25 ` Allen Li
2019-10-25 16:32 ` Robert Pluim
2019-10-26 9:44 ` Allen Li
2019-10-27 8:26 ` Robert Pluim
2019-11-05 17:40 ` Robert Pluim
2019-11-13 14:03 ` Robert Pluim
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).