GNU bug report logs - #37895
26.3; X protocol error: BadLength (poly request too large or internal Xlib length error) on protocol request 139

Previous Next

Package: emacs;

Reported by: Unknown <ax487 <at> gmx.de>

Date: Wed, 23 Oct 2019 22:35:01 UTC

Severity: normal

Tags: fixed

Merged with 37786

Found in version 26.3

Fixed in version 27.1

Done: Robert Pluim <rpluim <at> gmail.com>

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#37895; Package emacs. (Wed, 23 Oct 2019 22:35:04 GMT) Full text and rfc822 format available.

Acknowledgement sent to Unknown <ax487 <at> gmx.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Wed, 23 Oct 2019 22:35:04 GMT) Full text and rfc822 format available.

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

From: Unknown <ax487 <at> gmx.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.3; X protocol error: BadLength (poly request too large or
 internal Xlib length error) on protocol request 139
Date: Thu, 24 Oct 2019 00:14:13 +0200
Emacs crashes after triggering an X error message.

To reproduce the error, I have to start emacs as a daemon via

> emacs --fg-daemon

and a client via

> emacsclient -create-frame --alternate-editor=""

As soon as I open a source file (C++ in my case), emacs crashes
immediately based on the following X error:

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://gitlab.gnome.org/GNOME/gtk/issues/221
For details, see etc/PROBLEMS.
Fatal error 6: Aborted

This does *not* happen when I launch emacs directly.

Note: the bug seems to be very similar to the
one reported here:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30874#33

My emacs is (naturally) heavily modded, and I was not able to pinpoint
the problem to one concrete package. Noticably, I *can* enter the
unicode symbol 274c.

I suspect that the theme I am using (doom) triggers the rendering of
some unicode glyph or icon causing the error.

C-level backtrace:

#0  0x00007ffff57e87b5 in raise () at /usr/lib/libpthread.so.0
#1  0x00000000005686da in terminate_due_to_signal (sig=6,
backtrace_limit=40) at emacs.c:399
#2  0x0000000000590abf in emacs_abort () at sysdep.c:2426
#3  0x000000000052eb6a in x_connection_closed (dpy=0x4386c20,
error_message=0x7fffffff3d50 "X protocol error: BadLength (poly request
too large or internal Xlib length error) on protocol request 139",
ioerror=false) at xterm.c:9831
        dpyinfo = 0x44cb000
        frame = 12056501
        tail = 0
        idx = 41
#4  0x000000000052ed10 in x_error_quitter (display=0x4386c20,
event=0x7fffffff3ef0) at xterm.c:9919
        buf = "BadLength (poly request too large or internal Xlib
length error)", '\000' <repeats 191 times>
        buf1 = "X protocol error: BadLength (poly request too large or
internal Xlib length error) on protocol request
139\000\005\000\000\000\000\377\377\377\377\000\000\000\000E\271#\005\0
00\000\000\000\377\377\377\377\000\000\000\000Ź#\005\000\000\000\000\37
7\377\377\377\000\000\000\000E\272#\005\000\000\000\000\377\377\377\377
\000\000\000\000ź#\005\000\000\000\000\377\377\377\377\000\000\000\000\
000\237\350\353H!\363,\377\377\377\377\000\000\000\000\202#"...
#5  0x000000000052ec59 in x_error_handler (display=0x4386c20,
event=0x7fffffff3ef0) at xterm.c:9889
#6  0x00007ffff6e255db in _XError () at /usr/lib/libX11.so.6
#7  0x00007ffff6e22388 in  () at /usr/lib/libX11.so.6
#8  0x00007ffff6e22425 in  () at /usr/lib/libX11.so.6
#9  0x00007ffff6e22d8a in _XEventsQueued () at /usr/lib/libX11.so.6
#10 0x00007ffff6e04c3b in XFlush () at /usr/lib/libX11.so.6
#11 0x00007ffff6e420b9 in  () at /usr/lib/libX11.so.6
#12 0x00007ffff6e30312 in XDestroyIC () at /usr/lib/libX11.so.6
#13 0x000000000053a957 in free_frame_xic (f=0x4330800) at xfns.c:2676
#14 0x0000000000532df8 in x_free_frame_resources (f=0x4330800) at
xterm.c:11786
        dpyinfo = 0x44cb000
        hlinfo = 0x44cb0b8
#15 0x000000000053361e in x_destroy_window (f=0x4330800) at
xterm.c:11915
        dpyinfo = 0x44cb000
#16 0x0000000000428135 in delete_frame (frame=70453253, force=39552) at
frame.c:2049
        terminal = 0xb01ea0 <lispsym+39552>
        f = 0x4330800
        sf = 0xb7f7b0 <bss_sbrk_buffer+494864>
        kb = 0x563e87 <builtin_lisp_symbol+48>
        frames = 0
        frame1 = 12056501
        minibuffer_selected = 0
        is_tooltip_frame = 0
        nochild = true
#17 0x000000000052ead8 in x_connection_closed (dpy=0x4386c20,
error_message=0x7fffffff5430 "X protocol error: BadLength (poly request
too large or internal Xlib length error) on protocol request 139",
ioerror=false) at xterm.c:9810
        dpyinfo = 0x44cb000
        frame = 70453253
        tail = 68271507
        idx = 40
#18 0x000000000052ed10 in x_error_quitter (display=0x4386c20,
event=0x7fffffff55d0) at xterm.c:9919
        buf = "BadLength (poly request too large or internal Xlib
length error)", '\000' <repeats 191 times>
        buf1 = "X protocol error: BadLength (poly request too large or
internal Xlib length error) on protocol request
139\000\005\000\000\000\000\000\027$\005\000\000\000\000\240U\377\377\3
77\177\000\000\300T\377\377\377\177\000\000\000\237\350\353H!\363,4U\37
7\377\000\000\000\000\000\237\350\353H!\363,\000\000\000\000\000\000\00
0\000 <at> U\377\377\377\177\000\000\237Y\377\377\377\177\000\000\000\237\35
0\353H!\363,\353X\377\377\377\177\000\000\000\000\000\000\000\000\000\0
00"...
#19 0x000000000052ec59 in x_error_handler (display=0x4386c20,
event=0x7fffffff55d0) at xterm.c:9889
#20 0x00007ffff6e255db in _XError () at /usr/lib/libX11.so.6
#21 0x00007ffff6e22388 in  () at /usr/lib/libX11.so.6
#22 0x00007ffff6e22425 in  () at /usr/lib/libX11.so.6
#23 0x00007ffff6e22d8a in _XEventsQueued () at /usr/lib/libX11.so.6
#24 0x00007ffff6e14782 in XPending () at /usr/lib/libX11.so.6
#25 0x00007ffff766da00 in  () at /usr/lib/libgdk-3.so.0
#26 0x00007ffff6fb5a50 in g_main_context_prepare () at
/usr/lib/libglib-2.0.so.0
#27 0x00007ffff6fb6096 in  () at /usr/lib/libglib-2.0.so.0
#28 0x00007ffff6fb62ea in g_main_context_pending () at
/usr/lib/libglib-2.0.so.0
#29 0x00007ffff79aa530 in gtk_events_pending () at /usr/lib/libgtk-
3.so.0
#30 0x000000000052d445 in XTread_socket (terminal=0x42f3a40,
hold_quit=0x7fffffff5910) at xterm.c:9146
        count = 0
        event_found = false
        dpyinfo = 0x44cb000
#31 0x0000000000579cff in gobble_input () at keyboard.c:6919
        nr = 2000317537
        hold_quit = {
          kind = NO_EVENT,
          part = scroll_bar_nowhere,
          code = 0,
          modifiers = 0,
          x = 0,
          y = 0,
          timestamp = 0,
          frame_or_window = 0,
          arg = 0
        }
        next = 0xb7f630 <bss_sbrk_buffer+494480>
        nread = 0
        err = false
        t = 0x42f3a40
#32 0x000000000057a24f in handle_async_input () at keyboard.c:7156
        nread = 32767
#33 0x000000000057a26e in process_pending_signals () at keyboard.c:7170
#34 0x000000000057a2af in unblock_input_to (level=0) at keyboard.c:7185
#35 0x000000000057a2d4 in unblock_input () at keyboard.c:7204
#36 0x00000000006b9156 in xftfont_open (f=0x4330800, entity=86263589,
pixel_size=13) at xftfont.c:393
        result = FcResultMatch
        display = 0x4386c20
        val = 2
        filename = 84973412
        idx = 2
        font_object = 85188021
        pat = 0x451cb40
        match = 0x514f100
        xftfont_info = 0x513ddb0
        font = 0x513ddb0
        size = 13
        xftfont = 0x525fdc0
        spacing = 0
        i = 0
        extents = {
          width = 1476,
          height = 128,
          x = 0,
          y = 101,
          xOff = 1492,
          yOff = 0
        }
        ft_face = 0x4a403d0
        matrix = 0x50aef20
#37 0x0000000000637b91 in font_open_entity (f=0x4330800,
entity=86263589, pixel_size=13) at font.c:2903
        driver_list = 0x4171610
        objlist = 0
        size = 2
        val = 58176
        font_object = 140737488313144
        font = 0x5244725
        height = 32767
        psize = 13
        min_width = 0


In GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.12)
 of 2019-10-23 built on venla
Windowing system distributor 'The X.Org Foundation', version
11.0.12005000
System Description:	Arch Linux

Recent messages:
[yas] Prepared just-in-time loading of snippets successfully.
Loading /home/ax487/.emacs.d/yasnippet.el (source)...done
Loading /home/ax487/.emacs.d/zimpl.el (source)...done
Loading /home/ax487/.emacs.d/hydra.el (source)...done
Loading /home/ax487/.emacs.d/windmove.el (source)...done
Loading /home/ax487/.emacs.d/bindings.el (source)...
Loading /home/ax487/.emacs.d/functions.el (source)...done
Loading /home/ax487/.emacs.d/bindings.el (source)...done
Turning on magit-auto-revert-mode...done
For information about GNU Emacs and the GNU system, type C-h C-a.

Configured using:
 'configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib
 --localstatedir=/var --with-x-toolkit=gtk3 --with-xft --with-modules
 'CFLAGS=-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -O0 -ggdb
 -fvar-tracking-assignments
 -fdebug-prefix-map=/home/ax487/Downloads/emacs/src=/usr/src/debug'
 CPPFLAGS=-D_FORTIFY_SOURCE=2
 LDFLAGS=-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD LCMS2

Important settings:
  value of $LC_TIME: de_DE.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Emacs-Lisp

Minor modes in effect:
  savehist-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  smartparens-global-mode: t
  smartparens-mode: t
  global-magit-file-mode: t
  diff-auto-refine-mode: t
  magit-auto-revert-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  projectile-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  doom-modeline-mode: t
  shell-dirtrack-mode: t
  company-mode: t
  show-paren-mode: t
  override-global-mode: t
  global-hl-line-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/ax487/.emacs.d/elpa/cmake-mode-20190710.1319/cmake-mode hides
/usr/share/emacs/site-lisp/cmake-mode
/home/ax487/.emacs.d/elpa/protobuf-mode-20170526.1650/protobuf-mode
hides /usr/share/emacs/site-lisp/protobuf-mode
/home/ax487/.emacs.d/elpa/let-alist-1.0.6/let-alist hides
/usr/share/emacs/26.3/lisp/emacs-lisp/let-alist

Features:
(shadow sort flyspell ispell mail-extr face-remap emacsbug sendmail
ido-better-flex cl smex ido vc-mtn vc-hg vc-git vc-bzr vc-src vc-sccs
vc-svn vc-cvs vc-rcs vc vc-dispatcher company-oddmuse company-keywords
company-etags etags company-gtags company-dabbrev-code company-dabbrev
company-files company-capf company-cmake company-xcode company-clang
company-semantic company-eclim company-template company-bbdb savehist
windmove hydra lv zpl-mode string-inflection undo-tree diff
smartparens-config smartparens-python smartparens-markdown
smartparens-text smartparens magit-submodule magit-obsolete magit-blame
magit-stash magit-reflog magit-bisect magit-push magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag magit-merge magit-branch magit-reset
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log which-func magit-diff smerge-mode diff-mode
magit-core magit-autorevert autorevert magit-margin magit-transient
magit-process magit-mode transient git-commit magit-git magit-section
magit-utils crm log-edit message dired dired-loaddefs rfc822 mml mml-
sec
epa derived epg gnus-util rmail rmail-loaddefs mm-decode mm-bodies
mm-encode mailabbrev mail-utils gmm-utils mailheader pcvs-util add-log
with-editor async-bytecomp async server projectile grep ibuf-ext
ibuffer
ibuffer-loaddefs ccls ccls-member-hierarchy ccls-inheritance-hierarchy
ccls-call-hierarchy ccls-tree ccls-code-lens ccls-semantic-highlight
ccls-common lsp lsp-mode yasnippet elec-pair ewoc markdown-mode color
noutline outline tree-widget wid-edit xref spinner network-stream
starttls inline imenu ht filenotify em-glob esh-util dash-functional
bindat flymake-proc flymake compile warnings thingatpt project cc-mode
cc-fonts cc-guess cc-menus cc-cmds flycheck find-func doom-modeline
doom-modeline-segments doom-modeline-env doom-modeline-core subr-x
shrink-path f s dash all-the-icons all-the-icons-faces data-material
data-weathericons data-octicons data-fileicons data-faicons
data-alltheicons memoize doom-one-theme doom-themes doom-themes-base
modern-cpp-font-lock tern url-http tls gnutls url-auth mail-parse
rfc2231 rfc2047 rfc2045 mm-util ietf-drums mail-prsvr url-gw nsm rmc
puny url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util mailcap cython-mode python tramp-sh
tramp
tramp-compat tramp-loaddefs trampver ucs-normalize shell pcomplete
parse-time format-spec json map comint ring ansi-color company pcase
backup-each-save edmacro kmacro cl-extra help-mode ampl-mode paren
use-package use-package-ensure use-package-delight use-package-diminish
use-package-bind-key bind-key easy-mmode use-package-core finder-inf
tex-site advice rx info package easymenu epg-config url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache url-vars seq byte-opt gv bytecomp byte-compile cconv
cc-styles cc-align cc-engine cc-vars cc-defs cl-loaddefs cl-lib hl-line
cus-start cus-load time-date mule-util tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-
readable
backquote threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 528275 32285)
 (symbols 48 45789 1)
 (miscs 40 72 248)
 (strings 32 123767 7859)
 (string-bytes 1 3782826)
 (vectors 16 73534)
 (vector-slots 8 1192311 11202)
 (floats 8 805 433)
 (intervals 56 565 721)
 (buffers 992 12))





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37895; Package emacs. (Thu, 24 Oct 2019 13:59:01 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Unknown <ax487 <at> gmx.de>
Cc: 37895 <at> debbugs.gnu.org
Subject: Re: bug#37895: 26.3;
 X protocol error: BadLength (poly request too large or internal Xlib
 length error) on protocol request 139
Date: Thu, 24 Oct 2019 16:58:22 +0300
> From: Unknown <ax487 <at> gmx.de>
> Date: Thu, 24 Oct 2019 00:14:13 +0200
> 
> Emacs crashes after triggering an X error message.
> 
> To reproduce the error, I have to start emacs as a daemon via
> 
> > emacs --fg-daemon
> 
> and a client via
> 
> > emacsclient -create-frame --alternate-editor=""
> 
> As soon as I open a source file (C++ in my case), emacs crashes
> immediately based on the following X error:

Does this happen with _any_ file or just some?  If the latter, can you
try to figure out what is special about those files?

If this happens with any file, does it also happen with pure ASCII
files, like the README files in the Emacs distribution?

> Note: the bug seems to be very similar to the
> one reported here:
> 
> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30874#33
> 
> My emacs is (naturally) heavily modded, and I was not able to pinpoint
> the problem to one concrete package. Noticably, I *can* enter the
> unicode symbol 274c.

The backtrace seems to indicate that Emacs crashed trying to open some
font, so tracing the fonts Emacs loads might give a hint wrt what goes
wrong.

Thanks.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37895; Package emacs. (Thu, 24 Oct 2019 15:35:01 GMT) Full text and rfc822 format available.

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

From: Unknown <ax487 <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37895 <at> debbugs.gnu.org
Subject: Re: bug#37895: 26.3; X protocol error: BadLength (poly request too
 large or internal Xlib length error) on protocol request 139
Date: Thu, 24 Oct 2019 17:34:00 +0200
On Thu, 2019-10-24 at 16:58 +0300, Eli Zaretskii wrote:
> > From: Unknown <ax487 <at> gmx.de>
> > Date: Thu, 24 Oct 2019 00:14:13 +0200
> >
> > Emacs crashes after triggering an X error message.
> >
> > To reproduce the error, I have to start emacs as a daemon via
> >
> > > emacs --fg-daemon
> >
> > and a client via
> >
> > > emacsclient -create-frame --alternate-editor=""
> >
> > As soon as I open a source file (C++ in my case), emacs crashes
> > immediately based on the following X error:
>
> Does this happen with _any_ file or just some?  If the latter, can
> you
> try to figure out what is special about those files?
>
> If this happens with any file, does it also happen with pure ASCII
> files, like the README files in the Emacs distribution?

No, if I open the README, then everything works normally.

>
> > Note: the bug seems to be very similar to the
> > one reported here:
> >
> > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30874#33
> >
> > My emacs is (naturally) heavily modded, and I was not able to
> > pinpoint
> > the problem to one concrete package. Noticably, I *can* enter the
> > unicode symbol 274c.
>
> The backtrace seems to indicate that Emacs crashed trying to open
> some
> font, so tracing the fonts Emacs loads might give a hint wrt what
> goes
> wrong.

I have not included any additional fonts myself, but I guess the theme
does.

Regarding the tracing: As far as I can see the bottommost emacs code
being called is

static Lisp_Object
xftfont_open (struct frame *f, Lisp_Object entity, int pixel_size)

I also got

(gdb) call debug_print(entity)
#<font-entity xft GOOG JoyPixels nil iso10646-1 normal normal normal 0
nil nil 0 ((:font-entity "/usr/share/fonts/TTF/JoyPixels.ttf" . 0))>

Does that help?


>
> Thanks.





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37895; Package emacs. (Thu, 24 Oct 2019 16:24:02 GMT) Full text and rfc822 format available.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Unknown <ax487 <at> gmx.de>
Cc: 37895 <at> debbugs.gnu.org
Subject: Re: bug#37895: 26.3; X protocol error: BadLength (poly request too
 large or internal Xlib length error) on protocol request 139
Date: Thu, 24 Oct 2019 19:22:40 +0300
> From: Unknown <ax487 <at> gmx.de>
> Cc: 37895 <at> debbugs.gnu.org
> Date: Thu, 24 Oct 2019 17:34:00 +0200
> 
> Regarding the tracing: As far as I can see the bottommost emacs code
> being called is
> 
> static Lisp_Object
> xftfont_open (struct frame *f, Lisp_Object entity, int pixel_size)
> 
> I also got
> 
> (gdb) call debug_print(entity)
> #<font-entity xft GOOG JoyPixels nil iso10646-1 normal normal normal 0
> nil nil 0 ((:font-entity "/usr/share/fonts/TTF/JoyPixels.ttf" . 0))>

So your file included some emoji, is that correct?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37895; Package emacs. (Thu, 24 Oct 2019 18:07:02 GMT) Full text and rfc822 format available.

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

From: Unknown <ax487 <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37895 <at> debbugs.gnu.org
Subject: Re: bug#37895: 26.3; X protocol error: BadLength (poly request too
 large or internal Xlib length error) on protocol request 139
Date: Thu, 24 Oct 2019 20:06:35 +0200
On Thu, 2019-10-24 at 19:22 +0300, Eli Zaretskii wrote:
> > From: Unknown <ax487 <at> gmx.de>
> > Cc: 37895 <at> debbugs.gnu.org
> > Date: Thu, 24 Oct 2019 17:34:00 +0200
> >
> > Regarding the tracing: As far as I can see the bottommost emacs
> > code
> > being called is
> >
> > static Lisp_Object
> > xftfont_open (struct frame *f, Lisp_Object entity, int pixel_size)
> >
> > I also got
> >
> > (gdb) call debug_print(entity)
> > #<font-entity xft GOOG JoyPixels nil iso10646-1 normal normal
> > normal 0
> > nil nil 0 ((:font-entity "/usr/share/fonts/TTF/JoyPixels.ttf" .
> > 0))>
>
> So your file included some emoji, is that correct?

Well, that stands to reason. I suspect the doom-modeline package

https://github.com/seagle0128/doom-modeline

which relies heavily on icons and unicode symbols. In particular, there
are icons for the file types and minor modes. I think that opening a
C/C++ file activates some major/minor mode associated with an
icon/symbol triggering the error.






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37895; Package emacs. (Fri, 25 Oct 2019 16:38:01 GMT) Full text and rfc822 format available.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Unknown <ax487 <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 37895 <at> debbugs.gnu.org
Subject: Re: bug#37895: 26.3; X protocol error: BadLength (poly request too
 large or internal Xlib length error) on protocol request 139
Date: Fri, 25 Oct 2019 18:37:01 +0200
>>>>> On Thu, 24 Oct 2019 20:06:35 +0200, Unknown <ax487 <at> gmx.de> said:

    >> So your file included some emoji, is that correct?

    Unknown> Well, that stands to reason. I suspect the doom-modeline package

    Unknown> https://github.com/seagle0128/doom-modeline

    Unknown> which relies heavily on icons and unicode symbols. In particular, there
    Unknown> are icons for the file types and minor modes. I think that opening a
    Unknown> C/C++ file activates some major/minor mode associated with an
    Unknown> icon/symbol triggering the error.

Bug 37786 looks very similar to this (and on Arch Linux as well). If
you can build the emacs-26 branch, could you see if the following
patch fixes your crash?


diff --git i/lisp/international/fontset.el w/lisp/international/fontset.el
index c90d4f53bd..e80a1a87b9 100644
--- i/lisp/international/fontset.el
+++ w/lisp/international/fontset.el
@@ -804,7 +804,6 @@ setup-default-fontset
              #x2664
              (#x2667 . #x2669)
              (#x266C . #x26FF)
-             (#x2700 . #x27bF) ;; Dingbats
              (#x27C0 . #x27EF) ;; Misc Mathematical Symbols-A
              (#x27F0 . #x27FF) ;; Supplemental Arrows-A
              (#x2900 . #x297F) ;; Supplemental Arrows-B
diff --git i/src/ftfont.c w/src/ftfont.c
index 823fb2095c..017b349318 100644
--- i/src/ftfont.c
+++ w/src/ftfont.c
@@ -861,6 +861,9 @@ ftfont_list (struct frame *f, Lisp_Object spec)
 #endif /* FC_CAPABILITY */
 #ifdef FC_FONTFORMAT
                             FC_FONTFORMAT,
+#endif
+#ifdef FC_COLOR
+                             FC_COLOR,
 #endif
                             NULL);
   if (! objset)
@@ -902,6 +905,15 @@ ftfont_list (struct frame *f, Lisp_Object spec)
     {
       Lisp_Object entity;

+      {
+        FcBool b;
+        if (FcPatternGetBool (fontset->fonts[i], FC_COLOR, 0, &b)
+            == FcResultMatch && b)
+          {
+            fprintf (stderr, "Skipping Color font\n");
+            continue;
+          }
+      }
       if (spacing >= 0)
        {
          int this;




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37895; Package emacs. (Sun, 27 Oct 2019 08:10:01 GMT) Full text and rfc822 format available.

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Unknown <ax487 <at> gmx.de>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 37895 <at> debbugs.gnu.org
Subject: Re: bug#37895: 26.3; X protocol error: BadLength (poly request too
 large or internal Xlib length error) on protocol request 139
Date: Sun, 27 Oct 2019 09:09:42 +0100
Please keep 37895 <at> debbugs.gnu.org in the CC so we have everything in
one place.

    >> Bug 37786 looks very similar to this (and on Arch Linux as well). If
    >> you can build the emacs-26 branch, could you see if the following
    >> patch fixes your crash?
    >> 
    >> 

    Unknown> I applied the patch (with some tweaking) and it does seem to fix the
    Unknown> issue. Thank you very much :)

Thanks for testing, I hope the tweaking was not significant. Iʼll
merge this bug into 37786 and clean up the patch.

Regards




Merged 37786 37895. Request was from Robert Pluim <rpluim <at> gmail.com> to control <at> debbugs.gnu.org. (Sun, 27 Oct 2019 08:30:02 GMT) Full text and rfc822 format available.

Added tag(s) fixed. Request was from Robert Pluim <rpluim <at> gmail.com> to control <at> debbugs.gnu.org. (Wed, 13 Nov 2019 14:04:02 GMT) Full text and rfc822 format available.

bug marked as fixed in version 27.1, send any further explanations to 37786 <at> debbugs.gnu.org and Allen Li <darkfeline <at> felesatra.moe> Request was from Robert Pluim <rpluim <at> gmail.com> to control <at> debbugs.gnu.org. (Wed, 13 Nov 2019 14:04:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 12 Dec 2019 12:24:12 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 133 days ago.

Previous Next


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