bug#44930: 27.1; X protocol error: BadMatch (...) on protocol request 73

bug#44930: 27.1; X protocol error: BadMatch (...) on protocol request 73

[Francesco Potortì]

This looks like a regression since it has happened only since using
Emacs 27 (I had Emacs 26 running since a long time).

From the local machine, I run ssh on the remote one.  I launch Screen
and then I execute Emacs in text mode.  I use Screen remotely via ssh.
From the text frame I create an X frame running on a remote Xpra server
(which is a sort of Screen running on X), and I use the Xpra client
locally.

So I have an Emacs text frame on Screen and an X frame on a local Xpra
client.

I use (setq browse-url-browser-function 'w3m-browse-url)

Sometimes, when I use browse-url on an http URL, the X frame dies, but the
text frame stays alive and I can relaunch an X frame from there without
problems.  When the X frame dies, it leaves this error message:

X protocol error: BadMatch (invalid parameter attributes) on protocol request 73

Apparently this happens only when w3m does not respond immediately and
the *w3m* buffer displays a message asking to wait, but it only happened
few times until now, so I am not sure.


In GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2020-11-08, modified by Debian built on x86-ubc-01
Windowing system distributor 'The X.Org Foundation', version 11.0.12008000
System Description: Debian GNU/Linux bullseye/sid

Recent messages:
Expunging deleted messages...done
Saving file /home/pot/Mail/RMAIL...
Wrote /home/pot/Mail/RMAIL
Making completion list...
Quit
Saving file /home/pot/diary...
Preparing diary...done
Wrote /home/pot/diary
user-error: No undo information in this buffer
Report a bug for a [P]ackage or [F]ile: (default P) 
Quit
Configured using:
 'configure --build x86_64-linux-gnu --prefix=/usr
 --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var/lib --infodir=/usr/share/info
 --mandir=/usr/share/man --enable-libsystemd --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --build
 x86_64-linux-gnu --prefix=/usr --sharedstatedir=/var/lib
 --libexecdir=/usr/lib --localstatedir=/var/lib
 --infodir=/usr/share/info --mandir=/usr/share/man --enable-libsystemd
 --with-pop=yes
 --enable-locallisppath=/etc/emacs:/usr/local/share/emacs/27.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/27.1/site-lisp:/usr/share/emacs/site-lisp
 --with-sound=alsa --without-gconf --with-mailutils --with-x=yes
 --with-x-toolkit=lucid --with-toolkit-scroll-bars --without-gsettings
 'CFLAGS=-g -O2
 -fdebug-prefix-map=/build/emacs-6jKC2B/emacs-27.1+1=. -fstack-protector-strong
 -Wformat -Werror=format-security -Wall' 'CPPFLAGS=-Wdate-time
 -D_FORTIFY_SOURCE=2' LDFLAGS=-Wl,-z,relro'

Configured features:
XAW3D XPM JPEG TIFF GIF PNG RSVG SOUND GPM DBUS GLIB NOTIFY INOTIFY ACL
LIBSELINUX GNUTLS LIBXML2 FREETYPE HARFBUZZ M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS LUCID X11 XDBE XIM MODULES THREADS LIBSYSTEMD JSON
PDUMPER LCMS2 GMP

Important settings:
  value of $LC_COLLATE: it_IT.UTF-8
  value of $LC_CTYPE: it_IT.UTF-8
  value of $LC_NUMERIC: C
  value of $LANG: C.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Text

Minor modes in effect:
  filladapt-mode: t
  desktop-save-mode: t
  epa-global-mail-mode: t
  shell-dirtrack-mode: t
  openwith-mode: t
  xterm-mouse-mode: t
  display-time-mode: t
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t

Load-path shadows:
~/elisp/bhl hides /usr/share/emacs/site-lisp/bhl
/usr/share/emacs/site-lisp/elpa/debian-el-37/debian-autoloads hides /usr/share/emacs/site-lisp/elpa/gnuplot-mode-20141231/debian-autoloads
/usr/share/emacs/site-lisp/elpa/csv-mode-1.12/csv-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.12/csv-mode-pkg
/usr/share/emacs/site-lisp/elpa/csv-mode-1.12/csv-mode hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.12/csv-mode
/usr/share/emacs/site-lisp/elpa/csv-mode-1.12/csv-mode-tests hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.12/csv-mode-tests
/usr/share/emacs/site-lisp/elpa/csv-mode-1.12/csv-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/csv-mode-1.12/csv-mode-autoloads
/usr/share/emacs/site-lisp/elpa/debian-el-37/debian-el hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/debian-el
/usr/share/emacs/site-lisp/elpa/debian-el-37/gnus-BTS hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/gnus-BTS
/usr/share/emacs/site-lisp/elpa/debian-el-37/preseed hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/preseed
/usr/share/emacs/site-lisp/elpa/debian-el-37/deb-view hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/deb-view
/usr/share/emacs/site-lisp/elpa/debian-el-37/debian-el-autoloads hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/debian-el-autoloads
/usr/share/emacs/site-lisp/elpa/debian-el-37/apt-utils hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/apt-utils
/usr/share/emacs/site-lisp/elpa/debian-el-37/debian-bug hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/debian-bug
/usr/share/emacs/site-lisp/elpa/debian-el-37/debian-el-pkg hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/debian-el-pkg
/usr/share/emacs/site-lisp/elpa/debian-el-37/apt-sources hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/apt-sources
/usr/share/emacs/site-lisp/elpa/debian-el-37/debian-autoloads hides /usr/share/emacs/site-lisp/elpa-src/debian-el-37/debian-autoloads
/usr/share/emacs/site-lisp/elpa/dictionary-1.10/dictionary hides /usr/share/emacs/site-lisp/elpa-src/dictionary-1.10/dictionary
/usr/share/emacs/site-lisp/elpa/dictionary-1.10/link hides /usr/share/emacs/site-lisp/elpa-src/dictionary-1.10/link
/usr/share/emacs/site-lisp/elpa/dictionary-1.10/dictionary-pkg hides /usr/share/emacs/site-lisp/elpa-src/dictionary-1.10/dictionary-pkg
/usr/share/emacs/site-lisp/elpa/dictionary-1.10/dictionary-autoloads hides /usr/share/emacs/site-lisp/elpa-src/dictionary-1.10/dictionary-autoloads
/usr/share/emacs/site-lisp/elpa/dictionary-1.10/connection hides /usr/share/emacs/site-lisp/elpa-src/dictionary-1.10/connection
/usr/share/emacs/site-lisp/elpa/gnuplot-mode-20141231/gnuplot hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-mode-20141231/gnuplot
/usr/share/emacs/site-lisp/elpa/gnuplot-mode-20141231/gnuplot-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-mode-20141231/gnuplot-mode-pkg
/usr/share/emacs/site-lisp/elpa/debian-el-37/debian-autoloads hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-mode-20141231/debian-autoloads
/usr/share/emacs/site-lisp/elpa/gnuplot-mode-20141231/gnuplot-context hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-mode-20141231/gnuplot-context
/usr/share/emacs/site-lisp/elpa/gnuplot-mode-20141231/gnuplot-gui hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-mode-20141231/gnuplot-gui
/usr/share/emacs/site-lisp/elpa/gnuplot-mode-20141231/gnuplot-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/gnuplot-mode-20141231/gnuplot-mode-autoloads
/usr/share/emacs/site-lisp/elpa/markdown-mode-2.4/markdown-mode-autoloads hides /usr/share/emacs/site-lisp/elpa-src/markdown-mode-2.4/markdown-mode-autoloads
/usr/share/emacs/site-lisp/elpa/markdown-mode-2.4/markdown-mode hides /usr/share/emacs/site-lisp/elpa-src/markdown-mode-2.4/markdown-mode
/usr/share/emacs/site-lisp/elpa/markdown-mode-2.4/markdown-mode-pkg hides /usr/share/emacs/site-lisp/elpa-src/markdown-mode-2.4/markdown-mode-pkg
~/elisp/bibtex hides /usr/share/emacs/27.1/lisp/textmodes/bibtex
~/elisp/octave hides /usr/share/emacs/27.1/lisp/progmodes/octave
/usr/share/emacs/site-lisp/flim/sasl hides /usr/share/emacs/27.1/lisp/net/sasl
~/elisp/rmailout hides /usr/share/emacs/27.1/lisp/mail/rmailout

Features:
(debian-bug ediff ediff-merg ediff-mult ediff-wind ediff-diff ediff-help
ediff-init ediff-util smerge-mode compare-w rmail-spam-filter wdired
cal-move cal-x gnutls network-stream url-cache dabbrev rmailsort unrmail
undigest shadow emacsbug two-column iso-transl edmacro latexenc grep
arc-mode archive-mode url-http url-auth url-gw nsm w3m-filter w3m-cookie
markdown-mode rx noutline outline macros kmacro rmailedit debug
backtrace eieio-opt speedbar sb-image ezimage dframe find-func w3m-form
w3m-bookmark w3m-tabmenu w3m-session w3m doc-view jka-compr image-mode
exif timezone w3m-hist w3m-fb bookmark-w3m w3m-ems w3m-ccl ccl
w3m-favicon w3m-image w3m-proc w3m-util pp cl-print help-fns radix-tree
mailalias rmailout rect rmailkwd shr-color cus-edit cus-start cus-load
diff-mode easy-mmode diff cl-extra time-stamp dired-aux misearch
multi-isearch server conf-mode sh-script executable vc-dispatcher vc-svn
octave skeleton texinfo pcase tex-mode compile generic bibtex
vc-filewise vc-rcs mhtml-mode css-mode smie eww mm-url gnus nnheader
wid-edit url-queue url url-proxy url-privacy url-expand url-methods
url-history mailcap shr url-cookie url-domsuf url-util svg xml color js
imenu cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles cc-align
cc-engine cc-vars cc-defs sgml-mode dom qp rmailmm message rmc puny
rfc822 mml mml-sec gnus-util text-property-search mm-decode mm-bodies
mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231 desktop
frameset cal-julian solar cal-dst pot warnings rmailsum rmail
rmail-loaddefs sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mime-compose epa-mail mail-utils epa derived epg epg-config view
mule-util holidays hol-loaddefs appt diary-lib diary-loaddefs cal-menu
calendar cal-loaddefs tramp tramp-loaddefs trampver tramp-integration
files-x tramp-compat shell pcomplete comint ring parse-time iso8601
time-date ls-lisp format-spec bhl visual-fill-column switch-to-shell
openwith hi-lock anything-config anything advice woman man cl locate
xt-mouse ffap thingatpt scroll-in-place filladapt ansi-color time quail
help-mode dired-x dired dired-loaddefs generic-x disp-table finder-inf
w3m-load info debian-el package easymenu browse-url url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib 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 tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer 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 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
font-render-setting x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 16 705358 95183)
 (symbols 48 31974 0)
 (strings 32 148973 24999)
 (string-bytes 1 4675891)
 (vectors 16 53037)
 (vector-slots 8 1480670 149866)
 (floats 8 759 779)
 (intervals 56 52765 4485)
 (buffers 1000 123))

bug#44930: I can reproduce it

[Francesco Potortì]

In this moment I have a *w3m* buffer on a live Emacs.  If I switch to it
on a text frame, everything is well.  If I switch to it on an X display,
the frame dies (but Emacs survives).  The error is

X protocol error: BadMatch (invalid parameter attributes) on protocol request 73

until I don't kill the buffer, I can reproduce the error at will.  I
have no idea how to debug it.  If I am instructed, I can try until Emacs
is alive.

Xpra is apparently not relevant.  The same things happens on display :7
(where the Xpra server is running) and on display localhost:10.0

If I set debug-on-error this is what I read in the backtrace:

Debugger entered--Lisp error: (error "X protocol error: BadMatch (invalid parameter attributes) on protocol request 73")
  redisplay_internal\ \(C\ function\)()

bug#44930: I can reproduce it

[Eli Zaretskii]

> From: Francesco Potortì <pot@gnu.org>
> Date: Mon, 30 Nov 2020 22:46:56 +0100
> 
> In this moment I have a *w3m* buffer on a live Emacs.  If I switch to it
> on a text frame, everything is well.  If I switch to it on an X display,
> the frame dies (but Emacs survives).  The error is
> 
> X protocol error: BadMatch (invalid parameter attributes) on protocol request 73
> 
> until I don't kill the buffer, I can reproduce the error at will.  I
> have no idea how to debug it.  If I am instructed, I can try until Emacs
> is alive.

etc/DEBUG has some instructions for debugging X protocol errors;
search for "If you encounter X protocol errors".

In addition to what that says, it would be beneficial to understand
what kind of X request is "request 73".

bug#44930: I can reproduce it

[Francesco Potortì]

>> In this moment I have a *w3m* buffer on a live Emacs.  If I switch to it
>> on a text frame, everything is well.  If I switch to it on an X display,
>> the frame dies (but Emacs survives).  The error is
>> 
>> X protocol error: BadMatch (invalid parameter attributes) on protocol request 73
>> 
>> until I don't kill the buffer, I can reproduce the error at will.  I
>> have no idea how to debug it.  If I am instructed, I can try until Emacs
>> is alive.
>
>etc/DEBUG has some instructions for debugging X protocol errors;
>search for "If you encounter X protocol errors".

Ok.  I fear I will not be able to do that quickly.  

>In addition to what that says, it would be beneficial to understand
>what kind of X request is "request 73".

According to http://www.rahul.net/kenton/xproto/xrequests.html 73 is the
X protocol GetImage call.

According to https://www.x.org/wiki/guide/concepts/#index2h3, this is seldom
used, for example for making screenshots or for redrawing.  The second
usage could explain why it happens when I switch buffer and why the
debugger points to the internal C function redisplay_internal()

The XGetImage function is called twice from gtkutil.c and thrice from
image.c, so one of these is apparently failing.

According to
https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#requests:GetImage  
the call may return a Match error when the pixmap or window to be
returned do not satisfy certain geometric criteria.

This is strange, because the error happens only when I switch to a
specific buffer, which makes me think that it depends on the buffer
contents.  Is there a way to save the buffer contents including
attributes (fonts, overlays and other things that I do not know about)
to disk, so that I can easily recreate a buffer with the strange
property of causing this error?

bug#44930: I can reproduce it

[Eli Zaretskii]

> From: Francesco Potortì <pot@gnu.org>
> Date: Tue, 01 Dec 2020 18:19:54 +0100
> Cc: 44930@debbugs.gnu.org
> 
> This is strange, because the error happens only when I switch to a
> specific buffer, which makes me think that it depends on the buffer
> contents.  Is there a way to save the buffer contents including
> attributes (fonts, overlays and other things that I do not know about)
> to disk, so that I can easily recreate a buffer with the strange
> property of causing this error?

I know of no such way except writing Lisp that will recreate the
contents.

bug#44930: I can reproduce it

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > This is strange, because the error happens only when I switch to a
  > > specific buffer, which makes me think that it depends on the buffer
  > > contents.  Is there a way to save the buffer contents including
  > > attributes (fonts, overlays and other things that I do not know about)
  > > to disk, so that I can easily recreate a buffer with the strange
  > > property of causing this error?

  > I know of no such way except writing Lisp that will recreate the
  > contents.

It should be possible to write Lisp code to do that.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

bug#44930: I can reproduce it

[Francesco Potortì]

>>> In this moment I have a *w3m* buffer on a live Emacs.  If I switch to it
>>> on a text frame, everything is well.  If I switch to it on an X display,
>>> the frame dies (but Emacs survives).  The error is
>>> 
>>> X protocol error: BadMatch (invalid parameter attributes) on protocol request 73

I managed to find the time to compile emacs with symbols.

The previous instance of Emacs crashed, so apparently there is a serious
problem somewhere.

On the plus side, now apparently every instance of a *w3m* buffer
exhibits the problem, which is now easy to reproduce for me.

The error is:
  redisplay: X protocol error: BadMatch (invalid parameter attributes) on protocol request 73
which points to an XGetImage call where the pixmap or window to be
returned does not satisfy certain geometric criteria, according to
  https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#requests:GetImage  

Setting debug-on-error to t tells me that this happens inside
redisplay_internal().

I evaluated (x-synchronize t) and then switched to the *w3b* buffer.

Here is the backtrace.  If you help me I can try and continue debugging.

Current directory is ~/gnu/emacs-27.1+1/src/
GNU gdb (Debian 10.1-1+b1) 10.1
...
Reading symbols from ../debian/emacs-lucid/usr/bin/emacs-lucid...
Attaching to program: /home/pot/gnu/emacs-27.1+1/debian/emacs-lucid/usr/bin/emacs-lucid, process 95547
[New LWP 95548]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
0x00007fc663663926 in __pselect (nfds=9, readfds=0x7ffcc787bb40, writefds=0x7ffcc787bbc0, exceptfds=0x0, timeout=<optimized out>, sigmask=0x7ffcc787b950) at ../sysdeps/unix/sysv/linux/pselect.c:48
48	../sysdeps/unix/sysv/linux/pselect.c: No such file or directory.
SIGINT is used by the debugger.
Are you sure you want to change it? (y or n) [answered Y; input not from terminal]
DISPLAY = localhost:10.0
TERM = dumb
Breakpoint 2 at 0x5596a186fa29: file ./debian/build-src/src/xterm.c, line 10131.
(gdb) 
(gdb) c
Continuing.

Thread 1 "emacs" hit Breakpoint 2, x_error_quitter (display=0x5596a89b0990, event=0x7ffcc7879e90) at ./debian/build-src/src/xterm.c:10131
10131	{
(gdb) bt
#0  x_error_quitter (display=0x5596a89b0990, event=0x7ffcc7879e90) at ./debian/build-src/src/xterm.c:10131
#1  0x00005596a186fae1 in x_error_handler (display=<optimized out>, event=<optimized out>) at ./debian/build-src/src/xterm.c:10119
#2  0x00007fc6655fd36b in _XError () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#3  0x00007fc6655fa197 in  () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#4  0x00007fc6655fb373 in _XReply () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#5  0x00007fc6655e033a in XGetImage () at /usr/lib/x86_64-linux-gnu/libX11.so.6
#6  0x00005596a19c3788 in image_get_x_image (f=<optimized out>, img=img@entry=0x5596a57dccd0, mask_p=mask_p@entry=false) at ./debian/build-src/src/image.c:2934
#7  0x00005596a19c938e in image_background (img=0x5596a57dccd0, f=<optimized out>, pimg=pimg@entry=0x0) at ./debian/build-src/src/image.c:1376
#8  0x00005596a1870fed in x_setup_relief_colors (s=s@entry=0x7ffcc787a4b0) at ./debian/build-src/src/xterm.c:2735
#9  0x00005596a18733eb in x_draw_glyph_string_box (s=s@entry=0x7ffcc787a4b0) at ./debian/build-src/src/xterm.c:3025
#10 0x00005596a1873d14 in x_draw_glyph_string (s=0x7ffcc787a4b0) at ./debian/build-src/src/xterm.c:3966
#11 0x00005596a17e7bc4 in draw_glyphs (w=w@entry=0x5596a345c320, x=506, row=row@entry=0x5596a5fc8980, area=area@entry=TEXT_AREA, start=<optimized out>, start@entry=0, end=<optimized out>, end@entry=14, hl=<optimized out>, overlaps=<optimized out>) at ./debian/build-src/src/xdisp.c:28675
#12 0x00005596a17ea3c2 in gui_write_glyphs (w=0x5596a345c320, updated_row=0x5596a5fc8980, start=<optimized out>, updated_area=TEXT_AREA, len=14) at ./debian/build-src/src/xdisp.c:30702
#13 0x00005596a1790ca7 in update_text_area (w=w@entry=0x5596a345c320, updated_row=updated_row@entry=0x5596a5fc8980, vpos=vpos@entry=0) at ./debian/build-src/src/dispnew.c:3843
#14 0x00005596a17917a6 in update_window_line (w=w@entry=0x5596a345c320, vpos=vpos@entry=0, mouse_face_overwritten_p=mouse_face_overwritten_p@entry=0x7ffcc787b277) at ./debian/build-src/src/dispnew.c:4086
#15 0x00005596a1794231 in update_window (w=w@entry=0x5596a345c320, force_p=force_p@entry=true) at ./debian/build-src/src/dispnew.c:3612
#16 0x00005596a1794708 in update_frame (f=f@entry=0x5596a3767da0, force_p=true, force_p@entry=false, inhibit_hairy_id_p=inhibit_hairy_id_p@entry=false) at ./debian/build-src/src/dispnew.c:3214
#17 0x00005596a17e21ad in redisplay_internal () at ./debian/build-src/src/xdisp.c:15842
#18 0x00005596a17e364a in redisplay () at ./debian/build-src/src/xdisp.c:14989
Python Exception <class 'gdb.error'> value has been optimized out: 
#19 0x00005596a18ab1c4 in read_char (commandflag=1, map=, map@entry=XIL(0x5596a4254f73), prev_event=XIL(0x7ffcc787caa0), used_mouse_menu=used_mouse_menu@entry=0x7ffcc787c9cb, end_time=end_time@entry=0x0) at ./debian/build-src/src/keyboard.c:2493
#20 0x00005596a18ada5f in read_key_sequence (keybuf=keybuf@entry=0x7ffcc787caa0, prompt=XIL(0x15), dont_downcase_last=dont_downcase_last@entry=false, can_return_switch_frame=can_return_switch_frame@entry=true, fix_current_buffer=fix_current_buffer@entry=true, prevent_redisplay=prevent_redisplay@entry=false) at ./debian/build-src/src/keyboard.c:9553
#21 0x00005596a18ae5ce in command_loop_1 () at ./debian/build-src/src/keyboard.c:1350
Python Exception <class 'gdb.error'> value has been optimized out: 
#22 0x00005596a193096c in internal_condition_case (bfun=bfun@entry=0x5596a18ae34a <command_loop_1>, handlers=, hfun=hfun@entry=0x5596a18a26a9 <cmd_error>) at ./debian/build-src/src/eval.c:1356
Python Exception <class 'gdb.error'> value has been optimized out: 
#23 0x00005596a189c485 in command_loop_2 (ignore=, ignore@entry=XIL(0)) at ./debian/build-src/src/keyboard.c:1091
Python Exception <class 'gdb.error'> value has been optimized out: 
Python Exception <class 'gdb.error'> value has been optimized out: 
#24 0x00005596a19308b0 in internal_catch (tag=, func=func@entry=0x5596a189c461 <command_loop_2>, arg=, arg@entry=XIL(0)) at ./debian/build-src/src/eval.c:1117
#25 0x00005596a189c435 in command_loop () at ./debian/build-src/src/keyboard.c:1070
#26 0x00005596a18a22df in recursive_edit_1 () at ./debian/build-src/src/keyboard.c:714
#27 0x00005596a18a25cd in Frecursive_edit () at ./debian/build-src/src/keyboard.c:786
#28 0x00005596a189b050 in main (argc=3, argv=<optimized out>) at ./debian/build-src/src/emacs.c:2062

Lisp Backtrace:
"redisplay_internal (C function)" (0x0)
(gdb) c
Continuing.

bug#44930: I can reproduce it

[Alan Third]

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

On Sat, Dec 05, 2020 at 05:08:15PM +0100, Francesco Potortì wrote:
> >>> In this moment I have a *w3m* buffer on a live Emacs.  If I switch to it
> >>> on a text frame, everything is well.  If I switch to it on an X display,
> >>> the frame dies (but Emacs survives).  The error is
> >>> 
> >>> X protocol error: BadMatch (invalid parameter attributes) on protocol request 73
> 
> I managed to find the time to compile emacs with symbols.
> 
> The previous instance of Emacs crashed, so apparently there is a serious
> problem somewhere.
> 
> On the plus side, now apparently every instance of a *w3m* buffer
> exhibits the problem, which is now easy to reproduce for me.
> 
> The error is:
>   redisplay: X protocol error: BadMatch (invalid parameter attributes) on protocol request 73
> which points to an XGetImage call where the pixmap or window to be
> returned does not satisfy certain geometric criteria, according to
>   https://www.x.org/releases/X11R7.7/doc/xproto/x11protocol.html#requests:GetImage  
> 
> Setting debug-on-error to t tells me that this happens inside
> redisplay_internal().
> 
> I evaluated (x-synchronize t) and then switched to the *w3b* buffer.
> 
> Here is the backtrace.  If you help me I can try and continue debugging.
<snip>
> #5  0x00007fc6655e033a in XGetImage () at /usr/lib/x86_64-linux-gnu/libX11.so.6
> #6  0x00005596a19c3788 in image_get_x_image (f=<optimized out>, img=img@entry=0x5596a57dccd0, mask_p=mask_p@entry=false) at ./debian/build-src/src/image.c:2934
> #7  0x00005596a19c938e in image_background (img=0x5596a57dccd0, f=<optimized out>, pimg=pimg@entry=0x0) at ./debian/build-src/src/image.c:1376

Hmm, my suspicion here is that we're calling XGetImage with dimensions
that don't match the pixmap since we no longer store the dimensions of
the original image.

It hadn't occurred to me that we'd ever pull the image BACK from the X
server.

Can you try with the attached patch, please?
-- 
Alan Third

[-- Attachment #2: 0001-Fix-crash-when-using-XRender-and-restoring-image-fro.patch --]
[-- Type: text/plain, Size: 2056 bytes --]

From b2457ae612bd53c3d08cec7ddba703f400a78a2d Mon Sep 17 00:00:00 2001
From: Alan Third <alan@idiocy.org>
Date: Sat, 5 Dec 2020 19:40:08 +0000
Subject: [PATCH] Fix crash when using XRender and restoring image from X
 (bug#44930)

* src/dispextern.h (struct image): Add original dimension elements.
* src/image.c (image_set_transform): Store the original dimensions.
(image_get_x_image): If we're using transforms use the original
dimensions with XGetImage.
---
 src/dispextern.h | 4 ++++
 src/image.c      | 9 +++++++++
 2 files changed, 13 insertions(+)

diff --git a/src/dispextern.h b/src/dispextern.h
index da51772b37..c76822ff39 100644
--- a/src/dispextern.h
+++ b/src/dispextern.h
@@ -3040,6 +3040,10 @@ reset_mouse_highlight (Mouse_HLInfo *hlinfo)
 # if !defined USE_CAIRO && defined HAVE_XRENDER
   /* Picture versions of pixmap and mask for compositing.  */
   Picture picture, mask_picture;
+
+  /* We need to store the original image dimensions in case we have to
+     call XGetImage.  */
+  int original_width, original_height;
 # endif
 #endif	/* HAVE_X_WINDOWS */
 #ifdef HAVE_NTGUI
diff --git a/src/image.c b/src/image.c
index 5eb4132295..9494f9ddc6 100644
--- a/src/image.c
+++ b/src/image.c
@@ -2131,6 +2131,10 @@ image_set_transform (struct frame *f, struct image *img)
 # if !defined USE_CAIRO && defined HAVE_XRENDER
   if (!img->picture)
     return;
+
+  /* Store the original dimensions as we'll overwrite them later.  */
+  img->original_width = img->width;
+  img->original_height = img->height;
 # endif
 
   /* Determine size.  */
@@ -2990,6 +2994,11 @@ image_get_x_image (struct frame *f, struct image *img, bool mask_p)
 
   if (ximg_in_img)
     return ximg_in_img;
+#ifdef HAVE_XRENDER
+  else if (img->picture)
+    return XGetImage (FRAME_X_DISPLAY (f), !mask_p ? img->pixmap : img->mask,
+		      0, 0, img->original_width, img->original_height, ~0, ZPixmap);
+#endif
   else
     return XGetImage (FRAME_X_DISPLAY (f), !mask_p ? img->pixmap : img->mask,
 		      0, 0, img->width, img->height, ~0, ZPixmap);
-- 
2.29.2

bug#44930: I can reproduce it

[Francesco Potortì]

>Can you try with the attached patch, please?

I did.  It does not error any more with my previous bug reproducing
recipe.  If it does not happen in a week of normal usage I would say it
has gone away.

Thanks

bug#44930: I can reproduce it

[Alan Third]

On Sat, Dec 05, 2020 at 11:44:34PM +0100, Francesco Potortì wrote:
> >Can you try with the attached patch, please?
> 
> I did.  It does not error any more with my previous bug reproducing
> recipe.  If it does not happen in a week of normal usage I would say it
> has gone away.

I've pushed this to the emacs-27 branch.

Thanks!
-- 
Alan Third

bug#44930: I can reproduce it

[Francesco Potortì]

>On Sat, Dec 05, 2020 at 11:44:34PM +0100, Francesco Potortì wrote:
>> >Can you try with the attached patch, please?
>> 
>> I did.  It does not error any more with my previous bug reproducing
>> recipe.  If it does not happen in a week of normal usage I would say it
>> has gone away.
>
>I've pushed this to the emacs-27 branch.

I confirm that I have not observed the problem any more in conctinuous
emacs usage till now.

Thank you