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

[Eli Zaretskii]

[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.

Robert, how about backporting it to the emacs-26 branch, so that it
ends up in Emacs 26.2?