GNU bug report logs -
#37786
26.3; Emacs crashes when calling function to decode string
Previous Next
Reported by: Allen Li <darkfeline <at> felesatra.moe>
Date: Thu, 17 Oct 2019 04:12:01 UTC
Severity: normal
Tags: fixed
Merged with 37895
Found in version 26.3
Fixed in version 27.1
Done: Robert Pluim <rpluim <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37786 in the body.
You can then email your comments to 37786 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Thu, 17 Oct 2019 04:12:01 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Allen Li <darkfeline <at> felesatra.moe>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Thu, 17 Oct 2019 04:12:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Thu, 17 Oct 2019 04:23:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 37786 <at> debbugs.gnu.org (full text, mbox):
Allen Li <darkfeline <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Thu, 17 Oct 2019 09:54:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 37786 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 17 Oct 2019 06:22:10 +0200, Lars Ingebrigtsen <larsi <at> gnus.org> said:
Lars> Allen Li <darkfeline <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Fri, 18 Oct 2019 04:29:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 37786 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
>>>>>> On Thu, 17 Oct 2019 06:22:10 +0200, Lars Ingebrigtsen <larsi <at> gnus.org> said:
>
> Lars> Allen Li <darkfeline <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Fri, 18 Oct 2019 09:50:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 37786 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Thu, 17 Oct 2019 21:28:35 -0700, Allen Li <darkfeline <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Sat, 19 Oct 2019 01:19:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 37786 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
>>>>>> On Thu, 17 Oct 2019 21:28:35 -0700, Allen Li <darkfeline <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Mon, 21 Oct 2019 10:03:01 GMT)
Full text and
rfc822 format available.
Message #23 received at 37786 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Fri, 18 Oct 2019 18:18:34 -0700, Allen Li <darkfeline <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Tue, 22 Oct 2019 03:45:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 37786 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
>>>>>> On Fri, 18 Oct 2019 18:18:34 -0700, Allen Li <darkfeline <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Tue, 22 Oct 2019 08:19:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 37786 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Mon, 21 Oct 2019 20:44:09 -0700, Allen Li <darkfeline <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Wed, 23 Oct 2019 03:26:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 37786 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
>>>>>> On Mon, 21 Oct 2019 20:44:09 -0700, Allen Li <darkfeline <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Fri, 25 Oct 2019 16:33:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 37786 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Tue, 22 Oct 2019 20:25:40 -0700, Allen Li <darkfeline <at> 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;
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Sat, 26 Oct 2019 09:46:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 37786 <at> debbugs.gnu.org (full text, mbox):
Robert Pluim <rpluim <at> gmail.com> writes:
>>>>>> On Tue, 22 Oct 2019 20:25:40 -0700, Allen Li <darkfeline <at> 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;
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Sun, 27 Oct 2019 08:27:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 37786 <at> debbugs.gnu.org (full text, mbox):
>>>>> On Sat, 26 Oct 2019 02:44:52 -0700, Allen Li <darkfeline <at> 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
Merged 37786 37895.
Request was from
Robert Pluim <rpluim <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Sun, 27 Oct 2019 08:30:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Tue, 05 Nov 2019 17:41:03 GMT)
Full text and
rfc822 format available.
Message #46 received at 37786 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
>>>>> On Sun, 27 Oct 2019 09:26:35 +0100, Robert Pluim <rpluim <at> gmail.com> said:
>>>>> On Sat, 26 Oct 2019 02:44:52 -0700, Allen Li <darkfeline <at> 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.
[0001-Ignore-color-fonts-returned-from-FcFontList.patch (text/x-patch, inline)]
From aabd13bba282563410ef95764cad39f02ecb5d84 Mon Sep 17 00:00:00 2001
From: Robert Pluim <rpluim <at> gmail.com>
Date: Mon, 4 Nov 2019 17:44:57 +0100
Subject: [PATCH] Ignore color fonts returned from FcFontList
To: emacs-devel <at> 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
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#37786; Package
emacs.
(Wed, 13 Nov 2019 14:04:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 37786 <at> debbugs.gnu.org (full text, mbox):
tags 37786 fixed
close 37786 27.1
quit
Fixed by adding "Noto Color Emoji" to face-ignored-fonts
instead. Closing.
Committed as eae50e88ef
Added tag(s) fixed.
Request was from
Robert Pluim <rpluim <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Wed, 13 Nov 2019 14:04:02 GMT)
Full text and
rfc822 format available.
bug marked as fixed in version 27.1, send any further explanations to
37786 <at> debbugs.gnu.org and Allen Li <darkfeline <at> felesatra.moe>
Request was from
Robert Pluim <rpluim <at> gmail.com>
to
control <at> debbugs.gnu.org.
(Wed, 13 Nov 2019 14:04:02 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Thu, 12 Dec 2019 12:24:12 GMT)
Full text and
rfc822 format available.
This bug report was last modified 4 years and 136 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.