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

[Robert Pluim <rpluim@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4318 bytes --]

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.

> 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?

Thanks

Robert


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: out.patch --]
[-- Type: text/x-diff, Size: 1232 bytes --]

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;