GNU bug report logs - #53778
29.0.50; Can't start Emacs because of RenderBadPicture X protocol error

Previous Next

To reply to this bug, email your comments to 53778 AT debbugs.gnu.org.

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

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Can't start Emacs because of RenderBadPicture X protocol
 error
Date: Fri, 04 Feb 2022 11:07:43 -0300

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: 53778 <at> debbugs.gnu.org
Subject: 29.0.50;
 Can't start Emacs because of RenderBadPicture X protocol error
Date: Fri, 4 Feb 2022 11:38:46 -0300

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

I'm sorry, it seems the first message was sent without content.

After commit b944841173... I can't start GUI Emacs.

I did:
./configure && make

And when I start Emacs with "emacs -Q" I get:
X protocol error: RenderBadPicture (invalid Picture parameter) on protocol
request 138
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.
Backtrace:
./src/emacs(emacs_backtrace+0x41)[0x81bc731]
./src/emacs(terminate_due_to_signal+0x7f)[0x809958c]
./src/emacs[0x8099abd]
./src/emacs[0x8098b20]
./src/emacs[0x8167314]
./src/emacs[0x8167379]
/usr/lib/libX11.so.6(_XError+0x117)[0xb6f74ef7]
/usr/lib/libX11.so.6(+0x3f236)[0xb6f71236]
/usr/lib/libX11.so.6(+0x3f2cf)[0xb6f712cf]
/usr/lib/libX11.so.6(_XEventsQueued+0x81)[0xb6f71fd1]
/usr/lib/libX11.so.6(_XFlush+0x47)[0xb6f722f7]
/usr/lib/libX11.so.6(_XGetRequest+0x7c)[0xb6f756ac]
/usr/lib/libXext.so.6(XdbeDeallocateBackBufferName+0x5b)[0xb60e385b]
./src/emacs(tear_down_x_back_buffer+0x86)[0x8181446]
./src/emacs(x_free_frame_resources+0x49)[0x8176ed9]
./src/emacs[0x8177654]
./src/emacs(delete_frame+0x37e)[0x80b56de]
./src/emacs[0x8098aeb]
./src/emacs[0x8167314]
./src/emacs[0x8167379]
/usr/lib/libX11.so.6(_XError+0x117)[0xb6f74ef7]
/usr/lib/libX11.so.6(+0x3f236)[0xb6f71236]
/usr/lib/libX11.so.6(+0x3f2cf)[0xb6f712cf]
/usr/lib/libX11.so.6(_XReply+0x25c)[0xb6f726ec]
/usr/lib/libX11.so.6(XParseColor+0x1c9)[0xb6f608f9]
./src/emacs(x_parse_color+0xc7)[0x816e337]
./src/emacs(x_defined_color+0x71)[0x817f211]
./src/emacs[0x81612a4]
./src/emacs[0x816353e]
./src/emacs(face_at_buffer_position+0x2b7)[0x8165b47]
./src/emacs[0x80bdca5]
./src/emacs[0x80d7dbb]
./src/emacs[0x80d1396]
./src/emacs[0x80d9da7]
./src/emacs[0x80d7fae]
./src/emacs[0x80da04f]
./src/emacs(move_it_to+0x4c2)[0x80dc332]
./src/emacs(resize_mini_window+0x2ca)[0x80e53fa]
./src/emacs[0x80e604b]
./src/emacs[0x80c4d10]
./src/emacs[0x80ed195]


I'm not able to run GDB, but I bisected it to the following commit:
b944841173..: Håkon Flatval 2022-01-29 Add background transparency support
for GTK+Cairo
commit b944841173f12134e4c68d269d5b82b1820b2a40
Author: Håkon Flatval <hkon20 <at> hotmail.com>
Date:   Sat Jan 29 16:13:06 2022 +0100

  Add background transparency support for GTK+Cairo


In particular, if I revert the hunk in select_visual, the problem seems
to go away.


In GNU Emacs 29.0.50 (build 24, i686-pc-linux-gnu, GTK+ Version 2.24.33,
cairo version 1.16.0)
 of 2022-02-04 built on tbb.theblackbeard.org
Repository revision: 35cd9197fc3bda7576b3c343d1183360067dccd2
Repository branch: HEAD
Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
System Description: Slackware 14.2 i586 (post 14.2 -current)

Configured using:
 'configure LDFLAGS=-rdynamic'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND
SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XPM GTK2 ZLIB

Important settings:
  value of $LC_COLLATE: C
  value of $LANG: en_US.utf8
  locale-coding-system: utf-8-unix

Major mode: Message

Minor modes in effect:
  mml-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-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
  auto-fill-function: message-do-auto-fill
  transient-mark-mode: t
  abbrev-mode: t

Load-path shadows:
/home/tbb/.emacs.d/elpa/transient-20200819.1133/transient hides
/home/tbb/code/emacs/emacs/lisp/transient

Features:
(shadow emacsbug sendmail mail-extr message yank-media rmc puny rfc822
mml mml-sec epa derived epg rfc6068 epg-config mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
modus-vivendi-theme modus-themes init-web company-web dash company-css
web-completion-data company edmacro kmacro pcase init-ext init-emms dbus
emms-librefm-stream emms-librefm-scrobbler emms-playlist-limit
emms-volume emms-volume-mixerctl emms-volume-pulse emms-volume-amixer
emms-i18n emms-history emms-score emms-stream-info
emms-metaplaylist-mode emms-bookmarks emms-cue emms-mode-line-icon
emms-browser sort emms-playlist-sort emms-last-played emms-player-xine
emms-player-mpd tq emms-playing-time emms-lyrics emms-url emms-streams
emms-show-all emms-tag-editor emms-mark emms-mode-line emms-cache
emms-info-exiftool emms-info-tinytag emms-info-metaflac
emms-info-opusinfo emms-info-ogginfo emms-info-mp3info emms-info
emms-later-do emms-playlist-mode emms-player-vlc emms-player-mpv
emms-player-mplayer emms-player-simple emms-source-playlist
emms-source-file locate dired dired-loaddefs emms-setup emms emms-compat
init-gnus gnus nnheader gnus-util range init-org org-clock org ob
ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote org-src
ob-comint org-pcomplete pcomplete org-list org-faces org-entities
org-version ob-emacs-lisp ob-core ob-eval org-table oc-basic bibtex ol
rx org-keys oc org-compat advice org-macs org-loaddefs format-spec
find-func cal-menu calendar cal-loaddefs init-social newsticker
newst-treeview tree-widget wid-edit newst-plainview newst-reader
newst-ticker newst-backend iso8601 time-date xml init-octave init-rmail
undigest rmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
init-vc vc vc-dispatcher init-cc-mode init-c init-yasnippet init-eshell
eshell esh-cmd esh-ext esh-opt esh-proc esh-io esh-arg esh-module
esh-groups esh-util init-lisp slime compile text-property-search etags
fileloop generator xref project arc-mode archive-mode noutline outline
easy-mmode pp comint ansi-color ring hyperspec thingatpt init-elisp
init-global finder-inf init-package slime-autoloads info package
browse-url url url-proxy url-privacy url-expand url-methods url-history
url-cookie url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json map url-vars seq gv subr-x byte-opt bytecomp
byte-compile cconv cl-loaddefs cl-lib iso-transl tooltip eldoc paren
electric uniquify ediff-hook vc-hooks lisp-float-type elisp-mode 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 lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax 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 emoji-zwj charscript charprop case-table
epa-hook jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice
button loaddefs faces cus-face macroexp files window text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 8 418801 72363)
 (symbols 24 30139 5)
 (strings 16 130194 5004)
 (string-bytes 1 3637892)
 (vectors 8 49856)
 (vector-slots 4 1319110 112230)
 (floats 8 189 77)
 (intervals 28 481 0)
 (buffers 564 11))

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50;
 Can't start Emacs because of RenderBadPicture X protocol error
Date: Fri, 04 Feb 2022 16:52:29 +0200

> From: Mauro Aranda <maurooaranda <at> gmail.com>
> Date: Fri, 4 Feb 2022 11:38:46 -0300
> 
> After commit b944841173... I can't start GUI Emacs.
> 
> I did:
> ./configure && make
> 
> And when I start Emacs with "emacs -Q" I get:
> X protocol error: RenderBadPicture (invalid Picture parameter) on protocol request 138
> 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.
> Backtrace:
> ./src/emacs(emacs_backtrace+0x41)[0x81bc731]
> ./src/emacs(terminate_due_to_signal+0x7f)[0x809958c]
> ./src/emacs[0x8099abd]
> ./src/emacs[0x8098b20]

We need you to start Emacs under GDB, passing Emacs the command-line
option '-xrm "emacs.synchronous: true"', and then show the backtrace
inside GDB.  That should produce a much more useful backtrace than the
one you posted.

Why are you unable to run GDB?

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of RenderBadPicture
 X protocol error
Date: Fri, 4 Feb 2022 12:14:54 -0300

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

El vie, 4 feb 2022 a las 11:52, Eli Zaretskii (<eliz <at> gnu.org>) escribió:
>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>> Date: Fri, 4 Feb 2022 11:38:46 -0300
>>
>> After commit b944841173... I can't start GUI Emacs.
>>
>> I did:
>> ./configure && make
>>
>> And when I start Emacs with "emacs -Q" I get:
>> X protocol error: RenderBadPicture (invalid Picture parameter) on
protocol request 138
>> 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.
>> Backtrace:
>> ./src/emacs(emacs_backtrace+0x41)[0x81bc731]
>> ./src/emacs(terminate_due_to_signal+0x7f)[0x809958c]
>> ./src/emacs[0x8099abd]
>> ./src/emacs[0x8098b20]

> We need you to start Emacs under GDB, passing Emacs the command-line
> option '-xrm "emacs.synchronous: true"', and then show the backtrace
> inside GDB.  That should produce a much more useful backtrace than the
> one you posted.

I know, but...

> Why are you unable to run GDB?

With GDB 10.1, I get:

../../gdb/utils.c:671: internal-error: virtual memory exhausted: can't
allocate 4064 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.

I have never run into this problem before.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of RenderBadPicture
 X protocol error
Date: Fri, 04 Feb 2022 17:16:48 +0200

> From: Mauro Aranda <maurooaranda <at> gmail.com>
> Date: Fri, 4 Feb 2022 12:14:54 -0300
> Cc: 53778 <at> debbugs.gnu.org
> 
> With GDB 10.1, I get:
> 
> ../../gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 4064 bytes.
> A problem internal to GDB has been detected,
> further debugging may prove unreliable.

How much memory and how much swap do you have on that system?  Can you
enlarge the virtual memory available to applications (e.g., by
enlarging the amount of swap)?

Or maybe try a different version of GDB, either newer (GDB 11 was
released some time ago) or older.

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of
 RenderBadPicture X protocol error
Date: Fri, 04 Feb 2022 16:34:54 +0100

On Fri, 4 Feb 2022 11:38:46 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:

> I'm sorry, it seems the first message was sent without content.
>
> After commit b944841173... I can't start GUI Emacs.
>
> I did:
> ./configure && make
>
> And when I start Emacs with "emacs -Q" I get:
> X protocol error: RenderBadPicture (invalid Picture parameter) on protocol request 138
[...]
> I'm not able to run GDB, but I bisected it to the following commit:
> b944841173..: Håkon Flatval 2022-01-29 Add background transparency support for GTK+Cairo
> commit b944841173f12134e4c68d269d5b82b1820b2a40
> Author: Håkon Flatval <hkon20 <at> hotmail.com>
> Date:   Sat Jan 29 16:13:06 2022 +0100
>
>   Add background transparency support for GTK+Cairo
>
> In particular, if I revert the hunk in select_visual, the problem seems
> to go away.

I also got a crash after this commit, but Po Lu committed several
subsequent patches that fixed the problem for me.  Can you update and
see if it still crashes?

> In GNU Emacs 29.0.50 (build 24, i686-pc-linux-gnu, GTK+ Version 2.24.33, cairo version 1.16.0)
>  of 2022-02-04 built on tbb.theblackbeard.org
> Repository revision: 35cd9197fc3bda7576b3c343d1183360067dccd2
> Repository branch: HEAD
> Windowing system distributor 'The X.Org Foundation', version 11.0.12010000
> System Description: Slackware 14.2 i586 (post 14.2 -current)

Steve Berman

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of RenderBadPicture
 X protocol error
Date: Fri, 4 Feb 2022 12:45:26 -0300

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

On Fri, Feb 4, 2022, 12:16 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Mauro Aranda <maurooaranda <at> gmail.com>
>> Date: Fri, 4 Feb 2022 12:14:54 -0300
>> Cc: 53778 <at> debbugs.gnu.org
>>
>> With GDB 10.1, I get:
>>
>> ../../gdb/utils.c:671: internal-error: virtual memory exhausted: can't
allocate 4064 bytes.
>> A problem internal to GDB has been detected,
>> further debugging may prove unreliable.

> How much memory and how much swap do you have on that system?  Can you
> enlarge the virtual memory available to applications (e.g., by
> enlarging the amount of swap)?

bash-5.1$ free -m
               total        used        free      shared  buff/cache
available
Mem:            1883         554         523          34         806
 1083
Swap:           4095           0        4095

> Or maybe try a different version of GDB, either newer (GDB 11 was
> released some time ago) or older.

I'll see what I can do, thank you.

[Message part 2 (text/html, inline)]

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of RenderBadPicture
 X protocol error
Date: Fri, 4 Feb 2022 12:49:45 -0300

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

El vie, 4 feb 2022 a las 12:34, Stephen Berman (<stephen.berman <at> gmx.net>)
escribió:

>> I'm not able to run GDB, but I bisected it to the following commit:
>> b944841173..: Håkon Flatval 2022-01-29 Add background transparency
support for GTK+Cairo
>> commit b944841173f12134e4c68d269d5b82b1820b2a40
>> Author: Håkon Flatval <hkon20 <at> hotmail.com>
>> Date:   Sat Jan 29 16:13:06 2022 +0100
>>
>>   Add background transparency support for GTK+Cairo
>>
>> In particular, if I revert the hunk in select_visual, the problem seems
>> to go away.

> I also got a crash after this commit, but Po Lu committed several
> subsequent patches that fixed the problem for me.  Can you update and
> see if it still crashes?

Yes, I can't run Emacs from HEAD either.

[Message part 2 (text/html, inline)]

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

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of
 RenderBadPicture X protocol error
Date: Fri, 04 Feb 2022 16:49:58 +0100

On Fri, 4 Feb 2022 12:49:45 -0300 Mauro Aranda <maurooaranda <at> gmail.com> wrote:

> El vie, 4 feb 2022 a las 12:34, Stephen Berman (<stephen.berman <at> gmx.net>)
> escribió:
>
>>> I'm not able to run GDB, but I bisected it to the following commit:
>>> b944841173..: Håkon Flatval 2022-01-29 Add background transparency
> support for GTK+Cairo
>>> commit b944841173f12134e4c68d269d5b82b1820b2a40
>>> Author: Håkon Flatval <hkon20 <at> hotmail.com>
>>> Date:   Sat Jan 29 16:13:06 2022 +0100
>>>
>>>   Add background transparency support for GTK+Cairo
>>>
>>> In particular, if I revert the hunk in select_visual, the problem seems
>>> to go away.
>
>> I also got a crash after this commit, but Po Lu committed several
>> subsequent patches that fixed the problem for me.  Can you update and
>> see if it still crashes?
>
> Yes, I can't run Emacs from HEAD either.

Ok, then it's a different problem.

Steve Berman

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of RenderBadPicture
 X protocol error
Date: Fri, 04 Feb 2022 18:42:48 +0200

> From: Mauro Aranda <maurooaranda <at> gmail.com>
> Date: Fri, 4 Feb 2022 12:45:26 -0300
> Cc: 53778 <at> debbugs.gnu.org
> 
> 
> [1:text/plain Show]
> 
> 
> [2:text/html Hide Save:noname (1kB)]
> 
> On Fri, Feb 4, 2022, 12:16 Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
> >> From: Mauro Aranda <maurooaranda <at> gmail.com>
> >> Date: Fri, 4 Feb 2022 12:14:54 -0300
> >> Cc: 53778 <at> debbugs.gnu.org
> >> 
> >> With GDB 10.1, I get:
> >> 
> >> ../../gdb/utils.c:671: internal-error: virtual memory exhausted: can't allocate 4064 bytes.
> >> A problem internal to GDB has been detected,
> >> further debugging may prove unreliable.
> 
> > How much memory and how much swap do you have on that system?  Can you
> > enlarge the virtual memory available to applications (e.g., by
> > enlarging the amount of swap)?
> 
> bash-5.1$ free -m
>                total        used        free      shared  buff/cache   available
> Mem:            1883         554         523          34         806        1083
> Swap:           4095           0        4095
> 
> > Or maybe try a different version of GDB, either newer (GDB 11 was
> > released some time ago) or older.
> 
> I'll see what I can do, thank you.

In any case, it's strange that you cannot run GDB with 4.5GB of free
VM.  It should be enough.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of
 RenderBadPicture X protocol error
Date: Sat, 05 Feb 2022 09:11:47 +0800

Mauro Aranda <maurooaranda <at> gmail.com> writes:

> After commit b944841173... I can't start GUI Emacs.
>
> I did:
> ./configure && make
>
> And when I start Emacs with "emacs -Q" I get:
> X protocol error: RenderBadPicture (invalid Picture parameter) on protocol request 138
> 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.

That backtrace unfortunately doesn't help.  Please run Emacs under GDB
like this:

 (gdb) run -q -xrm 'Emacs.synchronous: true'

And show a backtrace from there instead.

The output of `xdpyinfo' on your system would be helpful as well.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: Mauro Aranda <maurooaranda <at> gmail.com>, 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of
 RenderBadPicture X protocol error
Date: Sat, 05 Feb 2022 09:13:24 +0800

Stephen Berman <stephen.berman <at> gmx.net> writes:

> I also got a crash after this commit, but Po Lu committed several
> subsequent patches that fixed the problem for me.  Can you update and
> see if it still crashes?

Those mostly involved inadquate programming throughout the rest of Emacs
that created pixmaps (or tooltip frames) of the wrong depth, causing
BadMatch errors.

RenderBadPicture errors point to something else sinister going on.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of
 RenderBadPicture X protocol error
Date: Sat, 05 Feb 2022 09:14:47 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> That backtrace unfortunately doesn't help.  Please run Emacs under GDB
> like this:
>
>  (gdb) run -q -xrm 'Emacs.synchronous: true'
>
> And show a backtrace from there instead.
>
> The output of `xdpyinfo' on your system would be helpful as well.

I'm sorry, I missed the part where you said you couldn't run GDB.

Does running Emacs like this solve the problem?

   path/to/emacs -q -xrm 'Emacs.visualClass: TrueColor-24'

Thanks.

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of RenderBadPicture
 X protocol error
Date: Sat, 5 Feb 2022 12:33:27 -0300

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

El vie, 4 feb 2022 a las 22:14, Po Lu (<luangruo <at> yahoo.com>) escribió:

> Does running Emacs like this solve the problem?
>
>    path/to/emacs -q -xrm 'Emacs.visualClass: TrueColor-24'

Sadly, no.

> Thanks.

Thanks for taking a look.

[Message part 2 (text/html, inline)]

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of RenderBadPicture
 X protocol error
Date: Sat, 5 Feb 2022 12:38:18 -0300

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

El vie, 4 feb 2022 a las 22:11, Po Lu (<luangruo <at> yahoo.com>) escribió:

> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>
> > After commit b944841173... I can't start GUI Emacs.
> >
> > I did:
> > ./configure && make
> >
> > And when I start Emacs with "emacs -Q" I get:
> > X protocol error: RenderBadPicture (invalid Picture parameter) on
protocol request 138
> > 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.

> That backtrace unfortunately doesn't help.  Please run Emacs under GDB
> like this:
>
>  (gdb) run -q -xrm 'Emacs.synchronous: true'
>
> And show a backtrace from there instead.

Haven't made any progress with GDB so far, sorry.

> The output of `xdpyinfo' on your system would be helpful as well.

xdpyinfo output attached.

[Message part 2 (text/html, inline)]

[xdpyinfo (application/octet-stream, attachment)]

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

From: Po Lu <luangruo <at> yahoo.com>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of
 RenderBadPicture X protocol error
Date: Sat, 05 Feb 2022 20:56:21 +0800

Mauro Aranda <maurooaranda <at> gmail.com> writes:

> Haven't made any progress with GDB so far, sorry.

I hope you get it working soon.

If you run Emacs with synchronization on outside gdb, wait for it to
crash, and run `coredumpctl debug', what happens?  A backtrace from such
a core dump would work as well.

> xdpyinfo output attached.

Thanks, unfortunately I see nothing out of the ordinary here.

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

From: Mauro Aranda <maurooaranda <at> gmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of
 RenderBadPicture X protocol error
Date: Thu, 10 Feb 2022 10:45:47 -0300

Po Lu <luangruo <at> yahoo.com> writes:

> Mauro Aranda <maurooaranda <at> gmail.com> writes:
>
>> Haven't made any progress with GDB so far, sorry.
>
> I hope you get it working soon.

I couldn't make it work.  I guess there's something wrong with
GDB on Slackware 14.2, because in a parallel XUbuntu installation I can
run GDB just fine.

> If you run Emacs with synchronization on outside gdb, wait for it to
> crash, and run `coredumpctl debug', what happens?  A backtrace from such
> a core dump would work as well.

No SystemD stuff in Slackware.


Anyway, I did a system update and I no longer see the RenderBadPicture
error.  I do see BadMatch errors but those has been fixed between the
reported commit and master.

I won't be able to help investigate the bug any further, so feel free to
close this bug report.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Mauro Aranda <maurooaranda <at> gmail.com>
Cc: 53778 <at> debbugs.gnu.org
Subject: Re: bug#53778: 29.0.50; Can't start Emacs because of
 RenderBadPicture X protocol error
Date: Fri, 11 Feb 2022 09:07:15 +0800

Mauro Aranda <maurooaranda <at> gmail.com> writes:

> No SystemD stuff in Slackware.

Too bad, you could locate and debug the core dump manually.

> Anyway, I did a system update and I no longer see the RenderBadPicture
> error.  I do see BadMatch errors but those has been fixed between the
> reported commit and master.

The only difference is that Emacs doesn't use XRender as eagerly as it
used to; so please set the frame parameter `alpha-background' to 0.9,
and see whether or not the crash can be reproduced.

> I won't be able to help investigate the bug any further, so feel free to
> close this bug report.

This is an actual problem and I can't see where it was solved, so please
don't close this report.

Thanks.

Previous Next

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