3

I find that on Ubuntu 18.04 LTS my emacs 24.5.1 crashes when I copy-and-paste the Unicode symbol "⛔" (no entry) or when I open a file with that character.

I have not encountered another Unicode symbol that crashes emacs (but I haven't tried a broad range). Furthermore, neither vi nor gedit crashes with that character. Firefox also handles the character correctly.

The error message I get reads:

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.

(emacs:21722): GLib-WARNING **: 23:00:15.207: g_main_context_prepare() called recursively from within a source's check() or prepare() member.

(emacs:21762): GLib-WARNING **: 23:04:25.943: g_main_context_check() called recursively from within a source's check() or prepare() member.
Fatal error 6: Aborted
Backtrace:
emacs[0x501a83]
emacs[0x4e803e]
emacs[0x501ac3]
emacs[0x4bc7df]
emacs[0x4be8ac]
emacs[0x4be90b]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XError+0x11a)[0x7f07d410a8ba]
/usr/lib/x86_64-linux-gnu/libX11.so.6(+0x3d7eb)[0x7f07d41077eb]
/usr/lib/x86_64-linux-gnu/libX11.so.6(+0x3d895)[0x7f07d4107895]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XEventsQueued+0x55)[0x7f07d41081c5]
/usr/lib/x86_64-linux-gnu/libX11.so.6(XFlush+0x1a)[0x7f07d40e974a]
/usr/lib/x86_64-linux-gnu/libX11.so.6(+0x5d10e)[0x7f07d412710e]
/usr/lib/x86_64-linux-gnu/libX11.so.6(XDestroyIC+0x12)[0x7f07d4115492]
emacs[0x4cd29c]
emacs[0x4c5f9c]
emacs[0x4c648b]
emacs[0x42583d]
emacs[0x4bc7a0]
emacs[0x4be8ac]
emacs[0x4be90b]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XError+0x11a)[0x7f07d410a8ba]
/usr/lib/x86_64-linux-gnu/libX11.so.6(+0x3d7eb)[0x7f07d41077eb]
/usr/lib/x86_64-linux-gnu/libX11.so.6(+0x3d895)[0x7f07d4107895]
/usr/lib/x86_64-linux-gnu/libX11.so.6(_XEventsQueued+0x55)[0x7f07d41081c5]
/usr/lib/x86_64-linux-gnu/libX11.so.6(XPending+0x5d)[0x7f07d40f9d3d]
/usr/lib/x86_64-linux-gnu/libgdk-3.so.0(+0x6808e)[0x7f07d592408e]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_prepare+0x1c8)[0x7f07d4870998]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(+0x4c36b)[0x7f07d487136b]
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_main_context_pending+0x27)[0x7f07d48714f7]
/usr/lib/x86_64-linux-gnu/libgtk-3.so.0(gtk_events_pending+0xd)[0x7f07d5de13fd]
emacs[0x4bc917]
emacs[0x4eeee9]
emacs[0x4f0565]
emacs[0x5bda65]
emacs[0x571b1c]
emacs[0x5bfe63]
emacs[0x5c0397]
emacs[0x5c0d23]
emacs[0x44106f]
emacs[0x4465f0]
emacs[0x44ab0a]
...
Aborted (core dumped)

Is this a bug that needs to be reported somewhere? Is there a workaround? I see there is a discussion at https://gitlab.gnome.org/GNOME/gtk/issues/221

3
  • 1
    On my Ubuntu 16.04, running "GNU Emacs 24.5.1 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9) of 2017-09-20 on lcy01-07, modified by Debian", and pasting from your title, it works, and gives me Char: ⛔ (9940, #o23324, #x26d4, file ...). Your problem may not be ⛔. – waltinator Sep 19 '18 at 21:41
  • On a 14.04 LTS with emacs 24.3.1 and gtk 3.10.8, I neither see a crash. I suppose it is a problem in 18.04 LTS – Finn Årup Nielsen Sep 19 '18 at 22:03
  • 1
    The emacscrashfile from bugs.launchpad.net/ubuntu/+source/emacs24/+bug/1735167 also crashes my 18.04 LTS. – Finn Årup Nielsen Sep 19 '18 at 22:11
4

Running the command

sudo apt-get remove fonts-noto-color-emoji 

fixed the crash for me.

2
  • I can confirm the fix: That the emoji still crashed my emacs and that after sudo apt-get remove fonts-noto-color-emoji, emacs no longer crashes (the emoji is represented with a box containing "26 D4"). – Finn Årup Nielsen Dec 3 '18 at 20:59
  • I confirm the problem and the solution for Ubuntu 19.04. Thank you – Carlos Dagorret Sep 25 '19 at 12:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.