bug#31547: 25.3; Core dump: g_main_context_prepare() called recursively from within a source's check() or prepare() member.

[Marc Wilhelm Küster]

On Mon, 04 Jun 2018 19:36:52 +0200,
Robert Pluim wrote:
> 
> [1  <text/plain; utf-8 (quoted-printable)>]
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > [Please keep the bug address on the CC list.]
> >
> >> From: Marc Wilhelm Küster <marc@budabe.eu>
> >> Date: Sun, 3 Jun 2018 22:40:00 +0200
> >> 
> >> When running the error case in gdb the behaviour changes in that it is 
> >> now possible to open the Sent folder without crash. However, scrolling 
> >> through the folder's contents causes Emacs to freeze (not crash) 
> >> reliably. When then interrupting the process in gdb and running a 
> >> backtrace, I get the following one (I've run this test a couple of times 
> >> with the same behaviour and substantially the same backtrace each time.
> >> 
> >> A possible "culprit" could be a mail with a mix of Latin and Greek 
> >> characters, but this is just a suspicion (I get a regularly mails with 
> >> both Latin and Greek characters which don't pose any problems)
> >> 
> >> Best regards,
> >> 
> >> Marc
> >> 
> >> (gdb) run -xrm "emacs.synchronous: true"
> >> Starting program: /home/mwkuster/src/emacs-26.1/src/emacs -xrm 
> >> "emacs.synchronous: true"
> >> [Thread debugging using libthread_db enabled]
> >> Using host libthread_db library "/usr/lib/libthread_db.so.1".
> >> [New Thread 0x7fffe7174700 (LWP 25375)]
> >> [New Thread 0x7fffe6506700 (LWP 25377)]
> >> [New Thread 0x7fffe4a51700 (LWP 25380)]
> >>     **** Emacs freezes while scrolling through the Folder *****
> >> ^C
> >> Thread 1 "emacs" received signal SIGINT, Interrupt.
> >> 0x00007ffff0cc2ffc in pthread_cond_wait@@GLIBC_2.3.2 () from 
> >> /usr/lib/libpthread.so.0
> >> (gdb) bt
> >> #0  0x00007ffff0cc2ffc in pthread_cond_wait@@GLIBC_2.3.2 () at 
> >> /usr/lib/libpthread.so.0
> >> #1  0x00007ffff468049d in _XReply () at /usr/lib/libX11.so.6
> >> #2  0x00007ffff467bfdd in XSync () at /usr/lib/libX11.so.6
> >> #3  0x00007ffff467c07b in  () at /usr/lib/libX11.so.6
> >> #4  0x00007ffff3dfaea8 in XftDrawDestroy () at /usr/lib/libXft.so.2
> >> #5  0x0000000000704769 in xftfont_end_for_frame (f=0x1483c30 
> >> <bss_sbrk_buffer+6598096>)
> >>      at xftfont.c:686
> >> #6  0x000000000067cd57 in font_update_drivers (f=0x1483c30 
> >> <bss_sbrk_buffer+6598096>, new_drivers=...) at font.c:3540
> >> #7  0x000000000042fba7 in delete_frame (frame=..., force=...) at 
> >> frame.c:2006
> >> #8  0x0000000000557223 in x_connection_closed (dpy=0x2ec1590, 
> >> error_message=0x7ffffffefd80 "X protocol error: BadLength (poly request 
> >> too large or internal Xlib length error) on protocol request 139", 
> >> ioerror=false) at xterm.c:9795
> >> #9  0x00000000005574a5 in x_error_quitter (display=0x2ec1590, 
> >> event=0x7ffffffeff30)
> >>      at xterm.c:9904
> >> #10 0x00000000005573f0 in x_error_handler (display=0x2ec1590, 
> >> event=0x7ffffffeff30)
> >>      at xterm.c:9874
> >> #11 0x00007ffff46826ed in _XError () at /usr/lib/libX11.so.6
> >> #12 0x00007ffff467f617 in  () at /usr/lib/libX11.so.6
> >> #13 0x00007ffff467f6d5 in  () at /usr/lib/libX11.so.6
> >> #14 0x00007ffff46805e8 in _XReply () at /usr/lib/libX11.so.6
> >> #15 0x00007ffff467bfdd in XSync () at /usr/lib/libX11.so.6
> >> #16 0x00007ffff467c07b in  () at /usr/lib/libX11.so.6
> >> #17 0x00007ffff400b136 in XRenderAddGlyphs () at /usr/lib/libXrender.so.1
> >> #18 0x00007ffff3dff9e2 in XftFontLoadGlyphs () at /usr/lib/libXft.so.2
> >> #19 0x00007ffff3dfc5b3 in XftGlyphExtents () at /usr/lib/libXft.so.2
> >> #20 0x00007ffff3dfc64a in XftTextExtents8 () at /usr/lib/libXft.so.2
> >> #21 0x0000000000703865 in xftfont_open (f=0x1483c30 
> >> <bss_sbrk_buffer+6598096>, entity=..., pixel_size=16) at xftfont.c:378
> >
> > This sounds like another case of bug#30045 and bug#30874.  In both
> > cases, there's a font that causes libXft to blow up.  If that's the
> > same bug, it should be solved on the master branch, see the commit
> > mentioned in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30874#114.
> >
> 
> Yes. Just as a sanity check, could you do
> 
> XFT_DEBUG=16 ./gdb
> 
> and then repeat the same commands? That should give us an indication
> of which font XFT is trying to open.

Dear Robert, Eli,

thanks a lot for your help! You're certainly right on your interpretation. Here 
is the stacktrace:

XFT_DEBUG=16 gdb ./emacs
GNU gdb (GDB) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./emacs...done.
warning: File "/home/mwkuster/src/emacs-26.1/src/.gdbinit" auto-loading has 
been declined by your `auto-load safe-path' set to 
"$debugdir:$datadir/auto-load".
To enable execution of this file add
        add-auto-load-safe-path /home/mwkuster/src/emacs-26.1/src/.gdbinit
line to your configuration file "/home/mwkuster/.gdbinit".
To completely disable this security protection add
        set auto-load safe-path /
line to your configuration file "/home/mwkuster/.gdbinit".
For more information about this security protection see the
"Auto-loading safe path" section in the GDB manual.  E.g., run from the shell:
        info "(gdb)Auto-loading safe path"
(gdb) run -xrm "emacs.synchronous: true"
Starting program: /home/mwkuster/src/emacs-26.1/src/emacs -xrm 
"emacs.synchronous: true"
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
[New Thread 0x7fffe7174700 (LWP 8933)]
[New Thread 0x7fffe6506700 (LWP 8934)]
XFT_DEBUG=16
[New Thread 0x7fffe4a51700 (LWP 8936)]
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches new
Loading file /usr/share/fonts/TTF/DejaVuSansMono.ttf/0
FontFile /usr/share/fonts/TTF/DejaVuSansMono-Oblique.ttf/0 matches new
Loading file /usr/share/fonts/TTF/DejaVuSansMono-Oblique.ttf/0
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/DejaVuSansMono-Bold.ttf/0 matches new
Loading file /usr/share/fonts/TTF/DejaVuSansMono-Bold.ttf/0
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinA.ttf/0 matches new
Loading file /usr/share/fonts/TTF/HanaMinA.ttf/0
FontFile /usr/share/fonts/TTF/HanaMinA.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinA.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinB.ttf/0 matches new
Loading file /usr/share/fonts/TTF/HanaMinB.ttf/0
FontFile /usr/share/fonts/TTF/HanaMinB.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinB.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinB.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinB.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinA.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinB.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/HanaMinA.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (3)
FontFile /usr/share/fonts/TTF/DejaVuSans.ttf/0 matches new
Loading file /usr/share/fonts/TTF/DejaVuSans.ttf/0
FontFile /usr/share/fonts/TTF/DejaVuSans-Oblique.ttf/0 matches new
Loading file /usr/share/fonts/TTF/DejaVuSans-Oblique.ttf/0
FontFile /usr/share/fonts/TTF/DejaVuSans.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/DejaVuSansMono-Bold.ttf/0 matches existing (2)
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (3)
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (3)
FontFile /usr/share/fonts/TTF/DejaVuSansMono.ttf/0 matches existing (3)
FontFile /usr/share/fonts/noto/NotoColorEmoji.ttf/0 matches new
Loading file /usr/share/fonts/noto/NotoColorEmoji.ttf/0
^C
Thread 1 "emacs" received signal SIGINT, Interrupt.
0x00007ffff0cc2ffc in pthread_cond_wait@@GLIBC_2.3.2 () from 
/usr/lib/libpthread.so.0
(gdb) bt
#0  0x00007ffff0cc2ffc in pthread_cond_wait@@GLIBC_2.3.2 () at 
/usr/lib/libpthread.so.0
#1  0x00007ffff468049d in _XReply () at /usr/lib/libX11.so.6
#2  0x00007ffff467bfdd in XSync () at /usr/lib/libX11.so.6
#3  0x00007ffff467c07b in  () at /usr/lib/libX11.so.6
#4  0x00007ffff3dfaea8 in XftDrawDestroy () at /usr/lib/libXft.so.2
#5  0x0000000000704769 in xftfont_end_for_frame (f=0x1483c30 
<bss_sbrk_buffer+6598096>)
    at xftfont.c:686
#6  0x000000000067cd57 in font_update_drivers (f=0x1483c30 
<bss_sbrk_buffer+6598096>, new_drivers=...) at font.c:3540
#7  0x000000000042fba7 in delete_frame (frame=..., force=...) at frame.c:2006
#8  0x0000000000557223 in x_connection_closed (dpy=0x2ec1590, 
error_message=0x7ffffffed1c0 "X protocol error: BadLength (poly request too 
large or internal Xlib length error) on protocol request 139", ioerror=false) 
at xterm.c:9795
#9  0x00000000005574a5 in x_error_quitter (display=0x2ec1590, 
event=0x7ffffffed370)
    at xterm.c:9904
#10 0x00000000005573f0 in x_error_handler (display=0x2ec1590, 
event=0x7ffffffed370)
    at xterm.c:9874
#11 0x00007ffff46826ed in _XError () at /usr/lib/libX11.so.6
#12 0x00007ffff467f617 in  () at /usr/lib/libX11.so.6
#13 0x00007ffff467f6d5 in  () at /usr/lib/libX11.so.6
#14 0x00007ffff46805e8 in _XReply () at /usr/lib/libX11.so.6
#15 0x00007ffff467bfdd in XSync () at /usr/lib/libX11.so.6
#16 0x00007ffff467c07b in  () at /usr/lib/libX11.so.6
#17 0x00007ffff400b136 in XRenderAddGlyphs () at /usr/lib/libXrender.so.1
#18 0x00007ffff3dff9e2 in XftFontLoadGlyphs () at /usr/lib/libXft.so.2
#19 0x00007ffff3dfc5b3 in XftGlyphExtents () at /usr/lib/libXft.so.2
#20 0x00007ffff3dfc64a in XftTextExtents8 () at /usr/lib/libXft.so.2
#21 0x0000000000703865 in xftfont_open (f=0x1483c30 <bss_sbrk_buffer+6598096>, 
entity=..., pixel_size=16) at xftfont.c:378
---Type <return> to continue, or q <return> to quit---q
Quit
(gdb) q
A debugging session is active.

        Inferior 1 [process 8929] will be killed.

Quit anyway? (y or n) y
[1]+  Done                    emacs  (wd: ~)


In addition, /usr/share/fonts/noto/NotoColorEmoji.ttf/0 is really a font I 
installed only a couple of months ago, though I make that connection only now

> 
> > Robert, how about backporting it to the emacs-26 branch, so that it
> > ends up in Emacs 26.2?
> 
> Sure. Perhaps a PROBLEMS entry as well? Although if itʼs backported
> the problem won't arise.
> 
> Marc, Iʼve attached the patch here, would it be possible for you to
> check if it fixes your problem?

Robert, I've just applied your patch - and the problem doesn't occur any more!

Thanks to both of you for your great help!

Best regards,

Marc

> 
> Thanks
> 
> Robert
> 
> [2 out.patch <text/x-diff (7bit)>]
> diff --git c/src/font.c i/src/font.c
> index e53935a15c..305bb14576 100644
> --- c/src/font.c
> +++ i/src/font.c
> @@ -5476,6 +5476,13 @@ Disabling compaction of font caches might enlarge the 
> Emacs memory
>  footprint in sessions that use lots of different fonts.  */);
>    inhibit_compacting_font_caches = 0;
>  
> +  DEFVAR_BOOL ("xft-ignore-color-fonts",
> +            Vxft_ignore_color_fonts,
> +            doc: /*
> +Non-nil means don't query fontconfig for color fonts, since they often
> +cause Xft crashes.  Only has an effect in Xft builds.  */);
> +  Vxft_ignore_color_fonts = 1;
> +
>  #ifdef HAVE_WINDOW_SYSTEM
>  #ifdef HAVE_FREETYPE
>    syms_of_ftfont ();
> diff --git c/src/ftfont.c i/src/ftfont.c
> index c2e093e633..8f048d2983 100644
> --- c/src/ftfont.c
> +++ i/src/ftfont.c
> @@ -764,6 +764,13 @@ ftfont_spec_pattern (Lisp_Object spec, char *otlayout, 
> struct OpenTypeSpec **ots
>    if (scalable >= 0
>        && ! FcPatternAddBool (pattern, FC_SCALABLE, scalable ? FcTrue : 
> FcFalse))
>      goto err;
> +#if defined HAVE_XFT && defined FC_COLOR
> +  /* We really don't like color fonts, they cause Xft crashes.  See
> +     Bug#30874.  */
> +  if (Vxft_ignore_color_fonts
> +      && ! FcPatternAddBool (pattern, FC_COLOR, FcFalse))
> +    goto err;
> +#endif
>  
>    goto finish;
>