GNU bug report logs - #30045
Emoji causing Emacs (GTK+3 backend) to crash

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 30045 in the body.
You can then email your comments to 30045 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Yegor Timoshenko <yegortimoshenko <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Emoji causing Emacs (GTK+3 backend) to crash
Date: Tue, 9 Jan 2018 17:37:33 +0000

Here is the Unicode symbol that causes Emacs to crash: ✅

Reproduced on the following Emacs/GTK versions:

GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
 of 2018-01-05

GNU Emacs 25.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.22.26)
 of 2017-12-20

Error log:

X protocol error: BadLength (poly request too large or internal Xlib
length error) on protocol request 139
When compiled with GTK, Emacs cannot recover from X disconnects.
This is a GTK bug: https://bugzilla.gnome.org/show_bug.cgi?id=85715
For details, see etc/PROBLEMS.
Fatal error 6: Aborted
(-emacs-wrapped:24344): GLib-WARNING **: g_main_context_prepare()
called recursively from within a source's check() or prepare() member.

(-emacs-wrapped:24344): GLib-WARNING **: g_main_context_check() called
recursively from within a source's check() or prepare() member.

Backtrace:
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x509e5c]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x4efa6b]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x509a63]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x4c359b]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x4c3896]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x4c391b]
/nix/store/x4cqrnzcvcc1lqvz41cp0dxqbnvsmhfk-libX11-1.6.5/lib/libX11.so.6(_XError+0x11d)[0x7effd711a13d]
/nix/store/x4cqrnzcvcc1lqvz41cp0dxqbnvsmhfk-libX11-1.6.5/lib/libX11.so.6(+0x42047)[0x7effd7117047]
/nix/store/x4cqrnzcvcc1lqvz41cp0dxqbnvsmhfk-libX11-1.6.5/lib/libX11.so.6(+0x42105)[0x7effd7117105]
/nix/store/x4cqrnzcvcc1lqvz41cp0dxqbnvsmhfk-libX11-1.6.5/lib/libX11.so.6(_XEventsQueued+0x55)[0x7effd7117a05]
/nix/store/x4cqrnzcvcc1lqvz41cp0dxqbnvsmhfk-libX11-1.6.5/lib/libX11.so.6(XFlush+0x1a)[0x7effd70f953a]
/nix/store/x4cqrnzcvcc1lqvz41cp0dxqbnvsmhfk-libX11-1.6.5/lib/libX11.so.6(+0x61aae)[0x7effd7136aae]
/nix/store/x4cqrnzcvcc1lqvz41cp0dxqbnvsmhfk-libX11-1.6.5/lib/libX11.so.6(XDestroyIC+0x12)[0x7effd7124a62]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x4d41ac]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x4cbeab]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x4cc2fb]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x4253a7]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x4c360b]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x4c3896]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x4c391b]
/nix/store/x4cqrnzcvcc1lqvz41cp0dxqbnvsmhfk-libX11-1.6.5/lib/libX11.so.6(_XError+0x11d)[0x7effd711a13d]
/nix/store/x4cqrnzcvcc1lqvz41cp0dxqbnvsmhfk-libX11-1.6.5/lib/libX11.so.6(+0x42047)[0x7effd7117047]
/nix/store/x4cqrnzcvcc1lqvz41cp0dxqbnvsmhfk-libX11-1.6.5/lib/libX11.so.6(+0x42105)[0x7effd7117105]
/nix/store/x4cqrnzcvcc1lqvz41cp0dxqbnvsmhfk-libX11-1.6.5/lib/libX11.so.6(_XEventsQueued+0x55)[0x7effd7117a05]
/nix/store/x4cqrnzcvcc1lqvz41cp0dxqbnvsmhfk-libX11-1.6.5/lib/libX11.so.6(XPending+0x57)[0x7effd7109697]
/nix/store/v2n1kfxk63p6ypwv3yi9yjp676hcsdyj-gtk+3-3.22.26/lib/libgdk-3.so.0(+0x683ae)[0x7effd8f7f3ae]
/nix/store/ciz98qjymi65iaq535nylgi36mx9m6jl-glib-2.54.2/lib/libglib-2.0.so.0(g_main_context_prepare+0x15d)[0x7effd78846fd]
/nix/store/ciz98qjymi65iaq535nylgi36mx9m6jl-glib-2.54.2/lib/libglib-2.0.so.0(+0x4a15b)[0x7effd788515b]
/nix/store/ciz98qjymi65iaq535nylgi36mx9m6jl-glib-2.54.2/lib/libglib-2.0.so.0(g_main_context_pending+0x27)[0x7effd7885307]
/nix/store/v2n1kfxk63p6ypwv3yi9yjp676hcsdyj-gtk+3-3.22.26/lib/libgtk-3.so.0(gtk_events_pending+0xd)[0x7effd943336d]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x4c374f]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x4f8c09]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x4f8ff5]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x5cbb87]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x57cbe4]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x5cdd04]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x5cdfab]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x5ceada]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x441507]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x44c848]
/nix/store/4znykvnf1xyflhq9z7albfb910xpl4i4-emacs-25.3/bin/.emacs-wrapped[0x44f538]
...
aborted

All software that Emacs 25.3.1 depends on, with versions:

glibc-2.26-75
util-linux-2.31
libffi-3.2.1
lz4-131
xz-5.2.3
libgpg-error-1.27
libgcrypt-1.8.1
libcap-2.25-lib
systemd-234-lib
bash-4.4-p12
libICE-1.0.9
libSM-1.2.2
libXau-1.0.8
libXdmcp-1.1.2
libxcb-1.12
libX11-1.6.5
dbus-1.10.24-lib
gcc-6.4.0-lib
zlib-1.2.11
pcre-8.41
glib-2.54.2
expat-2.2.5
libdaemon-0.14
avahi-0.7
gmp-6.1.2
ncurses-6.0-20171125
gobject-introspection-1.54.1
libXfixes-5.0.2
libXrender-0.9.10
libXcursor-1.1.15
nettle-3.4
openssl-1.0.2n
libevent-2.1.8
unbound-1.6.7-lib
libtasn1-4.12
dns-root-data-2017-10-24
libunistring-0.9.8
p11-kit-0.23.7
gnutls-3.6.1
libXpm-3.5.12
gsettings-desktop-schemas-3.24.1
dejavu-fonts-minimal-2.37
bzip2-1.0.6.0.1
libpng-apng-1.6.34
freetype-2.7.1
fontconfig-2.12.1-lib
atk-2.26.1
libXft-2.3.2
libXext-1.3.3
libXinerama-1.1.3
libXrandr-1.5.1
libjpeg-turbo-1.5.3
libtiff-4.0.8
libxml2-2.9.7
wayland-1.14.0
graphite2-1.3.6
libpciaccess-0.14
libdrm-2.4.88
libXxf86vm-1.1.4
libXdamage-1.1.4
libxshmfence-1.2
mesa-noglu-17.2.7
pixman-0.34.0
harfbuzz-1.7.1
cairo-1.14.10
pango-1.40.14
dconf-0.26.1-lib
libcroco-0.6.12
jasper-2.0.14
gdk-pixbuf-2.36.7
librsvg-2.40.19
libungif-4.1.4
gettext-0.19.8
epoxy-1.3.1
recordproto-1.14.2
libXi-1.7.9
libXtst-1.2.3
at-spi2-core-2.26.2
at-spi2-atk-2.26.1
libXcomposite-0.4.4
xkeyboard-config-2.22
libxkbcommon-0.7.2
cups-2.2.6-lib
gtk+3-3.22.26
libselinux-2.4
emacs-25.3

---

I also have Noto Emoji font installed, not sure if that changes the
issue. Perhaps this is only ever reproducible when there is some font
containing the glyph.

I'm not sure if I should file this against GNOME bug tracker, but the
fact that there is a symbol that causes Emacs to crash might be used
as a denial of service attack in some contexts (e.g. sending someone
an email, knowing that recipient uses Gnus), and knowing that seems to
be important.

Recompiling Emacs without GTK+3 fixes the issue:

GNU Emacs 27.0.50 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars)
 of 2018-01-09

Message #8 received at 30045 <at> debbugs.gnu.org (full text, mbox):

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: 30045 <at> debbugs.gnu.org
Subject: Triggered by trying to open Noto Color(sic) Emoji
Date: Tue, 9 Jan 2018 21:28:44 +0000 (GMT)

[Message part 1 (text/plain, inline)]

I can trigger this reliably by having N-C-E set as the font for
a particular character or range in my fontset, then inserting
said character (or having said character displayed and then tweaking
the fontset).

If I use Noto Emoji for that range (or explicitly use any other font
which _doesn't_ have a glyph for the triggering character) then
nothing bad happens other than a missing-glyph box in the buffer window.

I think the attempt to open the font kills the X connection as a side 
effect (presumably we're Doing Something Wrong) which then triggers the
rest of the crash once unblock_input() happens.

Backtrace attached.

[emacs-colour-emoji-explosion.log (application/octet-stream, attachment)]

Message #11 received at 30045 <at> debbugs.gnu.org (full text, mbox):

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: 30045 <at> debbugs.gnu.org
Subject: X protocol error and a test case
Date: Wed, 10 Jan 2018 20:47:54 +0000 (GMT)

[Message part 1 (text/plain, inline)]

This triggers the crash:

  (defun trigger-font-bork ()
    (interactive)
    (when window-system
      (let ((fontset (face-attribute 'default :fontset))
            (unisyms "Noto Color Emoji"))
        (set-fontset-font fontset '(#x1f900 . #x1f9ff) unisyms))
      (message "No-Boom: %c" #x2615 )
      (message "Boom   : %c" #x1f936)))

Changing unisyms to "Noto Emoji" stops the crash.

Getting out the printf() shotgun shows the crash is triggered around here,
in xftfont_open:

  if (spacing != FC_PROPORTIONAL
#ifdef FC_DUAL
      && spacing != FC_DUAL
#endif	/* FC_DUAL */
      )
    {
       // ...
    }
  else
    {
       // ...
    }
  unblock_input (); // <-- Boom today.

But that's just where the bug catches up with us - fiddling with the
block/unblock input calls can move the crash around a bit.

If we break out xtrace, the bad request can be found:

002:<:15b2: 12: RENDER-Request(139,17):
    CreateGlyphSet gsid=0x036002e1
                   format=0x00000023
002:<:15b3:17436: RENDER-Request(139,20):
    AddGlyphs glyphset=0x036002e1
              glyphids=0x00000441;
              glyphs={width=136 height=128 x=0 y=101 xOff=136 yOff=0};
              data=0x00,0x00,0x00, … } ← 17408 bytes

002:>:15b3:Error 16=Length: major=139, minor=20, bad=56623841

If I swap out the "Noto Color Emoji" font and request "Noto Emoji"
to avoid the crash, we still see AddGlyph requests, but they're much
smaller:

  #reqs size
      2 704
      2 600
      3 588
      3 556
      6 512
      5 508
      2 476
     15 468
      5 460
     16 428
     31 424
      5 412
      5 392
     40 388
     11 380
      3 364
     44 352
     38 348
      6 340
      5 336
     53 316
     11 308
      1 292
      4 288
      6 284
     62 280
     10 268
     55 252
      6 248
     14 244
      3 228
     23 224
      8 220
      7 208
      3 196
     26 188
      4 172
      5 168
      3 160
      2 156
      7 148
      4 140
      5 136
      1 128
      9 124
      1 112
      7 108
      7 100
      3 92
      3 88
      1 84
      5 76
      5 64
      5 60
      2 52
      2 48
      1 40
      6 28

So... either this request is flat-out too large (a bug? there aren't that 
many glyphs in N-C-E) and it needs to be chunked or we need to be telling
X we're going to be making bigger requests somehow.

Message #14 received at 30045 <at> debbugs.gnu.org (full text, mbox):

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: 30045 <at> debbugs.gnu.org
Subject: Re: X protocol error and a test case
Date: Thu, 11 Jan 2018 17:03:05 +0000 (GMT)

[Message part 1 (text/plain, inline)]

Looks like it gets triggered inside XftFontLoadGlyphs

  -> …/.libs/libXft.so.2.3.2(XftFontLoadGlyphs+0x716) [0x7f415551fd16]
  -> …/.libs/libXft.so.2.3.2(XftGlyphExtents+0x14b) [0x7f415551cf6b]
  -> [backtrace enters emacs proper]
  -> … (xftfont_text_extents)

but it would appear that the cause is that Xft can't process colour fonts
like Noto Color Emoji.

So we either have to:

  - hack on libXft until it can, and make that a requirement
  - use some other mechanism for colour fonts
  - exclude fonts like N-C-E /before/ we get to Xft so we don't crash

https://github.com/googlei18n/noto-emoji/issues/183

Message #17 received at 30045 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 30045 <at> debbugs.gnu.org
Subject: Re: bug#30045: X protocol error and a test case
Date: Tue, 20 Mar 2018 13:39:50 -0400

Vivek Dasmohapatra wrote:

>   - exclude fonts like N-C-E /before/ we get to Xft so we don't crash

Does it work to add "Noto Color Emoji" to the default value of
Vface_ignored_fonts in src/xfaces.c?

Message #20 received at 30045 <at> debbugs.gnu.org (full text, mbox):

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 30045 <at> debbugs.gnu.org
Subject: Re: bug#30045: X protocol error and a test case
Date: Thu, 22 Mar 2018 19:12:08 +0000 (GMT)

> Does it work to add "Noto Color Emoji" to the default value of
> Vface_ignored_fonts in src/xfaces.c?

I'll give it a try.

Message #37 received at 30045 <at> debbugs.gnu.org (full text, mbox):

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 30045 <at> debbugs.gnu.org
Subject: Re: bug#30045: X protocol error and a test case
Date: Tue, 12 Jun 2018 19:26:57 +0100 (BST)

> Does it work to add "Noto Color Emoji" to the default value of
> Vface_ignored_fonts in src/xfaces.c?

Sorry about the delay, got distracted.

Setting face-ignored-fonts to "Noto Color" prevented the crash.

Message #40 received at 30045 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 30045 <at> debbugs.gnu.org
Subject: Re: bug#30045: X protocol error and a test case
Date: Wed, 13 Jun 2018 16:17:40 +0200

Vivek Dasmohapatra <vivek <at> etla.org> writes:

>> Does it work to add "Noto Color Emoji" to the default value of
>> Vface_ignored_fonts in src/xfaces.c?
>
> Sorry about the delay, got distracted.
>
> Setting face-ignored-fonts to "Noto Color" prevented the crash.

Thanks for testing. A similar but more general fix was installed on
emacs-26 and master, would it be possible for you to test the latest
version of either of those?

Thanks

Robert

Message #43 received at 30045 <at> debbugs.gnu.org (full text, mbox):

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 30045 <at> debbugs.gnu.org
Subject: Re: bug#30045: X protocol error and a test case
Date: Wed, 13 Jun 2018 16:48:21 +0100 (BST)

> emacs-26 and master, would it be possible for you to test the latest
> version of either of those?

Sure, should be doable some time this week.

Message #52 received at 30045 <at> debbugs.gnu.org (full text, mbox):

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Glenn Morris <rgm <at> gnu.org>, 30045 <at> debbugs.gnu.org
Subject: Re: bug#30045: X protocol error and a test case
Date: Sun, 15 Jul 2018 18:19:19 +0100 (BST)

> Thanks for testing. A similar but more general fix was installed on
> emacs-26 and master, would it be possible for you to test the latest
> version of either of those?

Still breaks in 26.1 with the code I supplied earlier in the bug.

Message #55 received at 30045 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 30045 <at> debbugs.gnu.org
Subject: Re: bug#30045: X protocol error and a test case
Date: Mon, 16 Jul 2018 15:42:12 +0200

Vivek Dasmohapatra <vivek <at> etla.org> writes:

>> Thanks for testing. A similar but more general fix was installed on
>> emacs-26 and master, would it be possible for you to test the latest
>> version of either of those?
>
> Still breaks in 26.1 with the code I supplied earlier in the bug.

Is that release 26.1, or the HEAD of the emacs-26 branch? The fix was
not in release 26.1.

Regards

Robert

Message #58 received at 30045 <at> debbugs.gnu.org (full text, mbox):

From: Vivek Dasmohapatra <vivek <at> etla.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 30045 <at> debbugs.gnu.org
Subject: Re: bug#30045: X protocol error and a test case
Date: Mon, 16 Jul 2018 15:38:12 +0100 (BST)

> Is that release 26.1, or the HEAD of the emacs-26 branch? The fix was
> not in release 26.1.

Ah. I just tried with commit acaebed014 and there was no crash,
just the no-glyph box where the character would otherwise have
been, so it works as of then.

Message #61 received at 30045 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Vivek Dasmohapatra <vivek <at> etla.org>
Cc: 30045 <at> debbugs.gnu.org
Subject: Re: bug#30045: X protocol error and a test case
Date: Mon, 16 Jul 2018 17:55:49 +0200

Vivek Dasmohapatra <vivek <at> etla.org> writes:

>> Is that release 26.1, or the HEAD of the emacs-26 branch? The fix was
>> not in release 26.1.
>
> Ah. I just tried with commit acaebed014 and there was no crash,
> just the no-glyph box where the character would otherwise have
> been, so it works as of then.

OK, thanks for testing.

Regards

Robert

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.