* bug#44930: 27.1; X protocol error: BadMatch (...) on protocol request 73 @ 2020-11-28 19:36 Francesco Potortì 2020-11-30 21:46 ` bug#44930: I can reproduce it Francesco Potortì 0 siblings, 1 reply; 11+ messages in thread From: Francesco Potortì @ 2020-11-28 19:36 UTC (permalink / raw) To: 44930 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)) ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#44930: I can reproduce it 2020-11-28 19:36 bug#44930: 27.1; X protocol error: BadMatch (...) on protocol request 73 Francesco Potortì @ 2020-11-30 21:46 ` Francesco Potortì 2020-12-01 15:14 ` Eli Zaretskii 0 siblings, 1 reply; 11+ messages in thread From: Francesco Potortì @ 2020-11-30 21:46 UTC (permalink / raw) To: 44930 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\)() ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#44930: I can reproduce it 2020-11-30 21:46 ` bug#44930: I can reproduce it Francesco Potortì @ 2020-12-01 15:14 ` Eli Zaretskii 2020-12-01 17:19 ` Francesco Potortì 2020-12-05 16:08 ` Francesco Potortì 0 siblings, 2 replies; 11+ messages in thread From: Eli Zaretskii @ 2020-12-01 15:14 UTC (permalink / raw) To: Francesco Potortì; +Cc: 44930 > 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". ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#44930: I can reproduce it 2020-12-01 15:14 ` Eli Zaretskii @ 2020-12-01 17:19 ` Francesco Potortì 2020-12-01 18:29 ` Eli Zaretskii 2020-12-05 16:08 ` Francesco Potortì 1 sibling, 1 reply; 11+ messages in thread From: Francesco Potortì @ 2020-12-01 17:19 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 44930 >> 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? ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#44930: I can reproduce it 2020-12-01 17:19 ` Francesco Potortì @ 2020-12-01 18:29 ` Eli Zaretskii 2020-12-02 4:28 ` Richard Stallman 0 siblings, 1 reply; 11+ messages in thread From: Eli Zaretskii @ 2020-12-01 18:29 UTC (permalink / raw) To: Francesco Potortì; +Cc: 44930 > 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#44930: I can reproduce it 2020-12-01 18:29 ` Eli Zaretskii @ 2020-12-02 4:28 ` Richard Stallman 0 siblings, 0 replies; 11+ messages in thread From: Richard Stallman @ 2020-12-02 4:28 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 44930 [[[ 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) ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#44930: I can reproduce it 2020-12-01 15:14 ` Eli Zaretskii 2020-12-01 17:19 ` Francesco Potortì @ 2020-12-05 16:08 ` Francesco Potortì 2020-12-05 19:44 ` Alan Third 1 sibling, 1 reply; 11+ messages in thread From: Francesco Potortì @ 2020-12-05 16:08 UTC (permalink / raw) To: Francesco Potortì; +Cc: 44930 >>> 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#44930: I can reproduce it 2020-12-05 16:08 ` Francesco Potortì @ 2020-12-05 19:44 ` Alan Third 2020-12-05 22:44 ` Francesco Potortì 0 siblings, 1 reply; 11+ messages in thread From: Alan Third @ 2020-12-05 19:44 UTC (permalink / raw) To: Francesco Potortì; +Cc: 44930 [-- 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* bug#44930: I can reproduce it 2020-12-05 19:44 ` Alan Third @ 2020-12-05 22:44 ` Francesco Potortì 2020-12-12 10:43 ` Alan Third 0 siblings, 1 reply; 11+ messages in thread From: Francesco Potortì @ 2020-12-05 22:44 UTC (permalink / raw) To: Alan Third; +Cc: 44930 >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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#44930: I can reproduce it 2020-12-05 22:44 ` Francesco Potortì @ 2020-12-12 10:43 ` Alan Third 2020-12-12 13:09 ` Francesco Potortì 0 siblings, 1 reply; 11+ messages in thread From: Alan Third @ 2020-12-12 10:43 UTC (permalink / raw) To: Francesco Potortì; +Cc: 44930-done 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* bug#44930: I can reproduce it 2020-12-12 10:43 ` Alan Third @ 2020-12-12 13:09 ` Francesco Potortì 0 siblings, 0 replies; 11+ messages in thread From: Francesco Potortì @ 2020-12-12 13:09 UTC (permalink / raw) To: Alan Third; +Cc: 44930-done, 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. I confirm that I have not observed the problem any more in conctinuous emacs usage till now. Thank you ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2020-12-12 13:09 UTC | newest] Thread overview: 11+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-11-28 19:36 bug#44930: 27.1; X protocol error: BadMatch (...) on protocol request 73 Francesco Potortì 2020-11-30 21:46 ` bug#44930: I can reproduce it Francesco Potortì 2020-12-01 15:14 ` Eli Zaretskii 2020-12-01 17:19 ` Francesco Potortì 2020-12-01 18:29 ` Eli Zaretskii 2020-12-02 4:28 ` Richard Stallman 2020-12-05 16:08 ` Francesco Potortì 2020-12-05 19:44 ` Alan Third 2020-12-05 22:44 ` Francesco Potortì 2020-12-12 10:43 ` Alan Third 2020-12-12 13:09 ` Francesco Potortì
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).