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