GNU bug report logs - #77988
31.0.50; No more images after fullscreen and load-theme

Previous Next

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

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

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

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; No more images after fullscreen and load-theme
Date: Tue, 22 Apr 2025 16:12:45 +0200

Hi,

I have a nasty bug with the following minimal recipe:

       - emacs -Q
       - M-: (find-file "etc/images/gnus/gnus.svg")
       - M-: (set-frame-parameter nil 'fullscreen 'fullboth)
       - M-: (load-theme 'modus-operandi)

The image disappears (or is replaced by garbage) and I'm not able to
open any other image afterward.  FWIW, it seems that this bug only shows
on a lucid build.


In GNU Emacs 31.0.50 (build 5, x86_64-unknown-openbsd7.7, X toolkit) of
 2025-04-22 built on computer
Repository revision: 871ec9615a949e967bf7d19466eb9c56ed80ff7e
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101016
System Description: OpenBSD computer 7.7 GENERIC.MP#625 amd64

Configured using:
 'configure CC=egcc CPPFLAGS=-I/usr/local/include
 LDFLAGS=-L/usr/local/lib MAKEINFO=gmakeinfo --prefix=/home/manuel/emacs
 --bindir=/home/manuel/bin --with-x-toolkit=lucid
 --with-toolkit-scroll-bars=no --without-cairo
 --without-compress-install'

Configured features:
DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG LCMS2 LIBOTF
LIBXML2 M17N_FLT MODULES NOTIFY KQUEUE PDUMPER PNG RSVG SQLITE3 THREADS
TIFF TREE_SITTER WEBP X11 XAW3D XDBE XFT XIM XINERAMA XINPUT2 XPM XRANDR
LUCID ZLIB

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Group

Minor modes in effect:
  gnus-topic-mode: t
  debbugs-browse-mode: t
  bug-reference-mode: t
  display-time-mode: t
  display-battery-mode: t
  desktop-save-mode: t
  exwm-randr-mode: t
  server-mode: t
  gnus-undo-mode: t
  electric-pair-mode: t
  override-global-mode: t
  repeat-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  minibuffer-regexp-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
/home/manuel/prog/elisp/exwm/exwm hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm
/home/manuel/prog/elisp/exwm/exwm-xsettings hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-xsettings
/home/manuel/prog/elisp/exwm/exwm-xim hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-xim
/home/manuel/prog/elisp/exwm/exwm-workspace hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-workspace
/home/manuel/prog/elisp/exwm/exwm-randr hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-randr
/home/manuel/prog/elisp/exwm/exwm-manage hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-manage
/home/manuel/prog/elisp/exwm/exwm-layout hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-layout
/home/manuel/prog/elisp/exwm/exwm-input hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-input
/home/manuel/prog/elisp/exwm/exwm-floating hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-floating
/home/manuel/prog/elisp/exwm/exwm-systemtray hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-systemtray
/home/manuel/prog/elisp/exwm/exwm-core hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-core
/home/manuel/prog/elisp/exwm/exwm-background hides /home/manuel/.emacs.d/elpa/exwm-0.33/exwm-background
/home/manuel/.emacs.d/elpa/ef-themes-1.9.0/theme-loaddefs hides /home/manuel/emacs/share/emacs/31.0.50/lisp/theme-loaddefs
/home/manuel/.emacs.d/elpa/idlwave-6.5.1/idlwave hides /home/manuel/emacs/share/emacs/31.0.50/lisp/obsolete/idlwave
/home/manuel/.emacs.d/elpa/idlwave-6.5.1/idlw-toolbar hides /home/manuel/emacs/share/emacs/31.0.50/lisp/obsolete/idlw-toolbar
/home/manuel/.emacs.d/elpa/idlwave-6.5.1/idlw-shell hides /home/manuel/emacs/share/emacs/31.0.50/lisp/obsolete/idlw-shell
/home/manuel/.emacs.d/elpa/idlwave-6.5.1/idlw-help hides /home/manuel/emacs/share/emacs/31.0.50/lisp/obsolete/idlw-help
/home/manuel/.emacs.d/elpa/idlwave-6.5.1/idlw-complete-structtag hides /home/manuel/emacs/share/emacs/31.0.50/lisp/obsolete/idlw-complete-structtag

Features:
(shadow emacsbug lisp-mnt sort gnus-cite flow-fill mail-extr textsec
uni-scripts idna-mapping ucs-normalize uni-confusable textsec-check
gnus-async gnus-bcklg gnus-ml disp-table gnus-topic mm-archive url-cache
qp utf-7 imap rfc2104 nndoc nndraft nnmh network-stream nnfolder nnml
gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-cache
gnus-demon nntp nnrss misearch multi-isearch tex-mode slime-asdf grep
slime-tramp tramp trampver tramp-integration tramp-message tramp-compat
shell tramp-loaddefs slime-fancy slime-indentation slime-cl-indent
cl-indent slime-trace-dialog slime-fontifying-fu slime-package-fu
slime-references slime-compiler-notes-tree advice slime-scratch
slime-presentations slime-macrostep slime-mdot-fu
slime-enclosing-context slime-fuzzy slime-fancy-trace
slime-fancy-inspector slime-c-p-c slime-editing-commands slime-autodoc
slime-repl slime-parse slime apropos etags fileloop xref arc-mode
archive-mode hyperspec semantic/wisent/grammar semantic/bovine
semantic/grammar help-fns radix-tree semantic/idle semantic/analyze
semantic/sort semantic/scope semantic/analyze/fcn semantic/db
semantic/grammar-wy semantic/format semantic/tag-ls semantic/find
semantic/ctxt semantic/wisent semantic/wisent/wisent semantic/util-modes
semantic/util semantic semantic/tag semantic/lex semantic/fw mode-local
cedet org-agenda rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc
rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn nxml-ns
nxml-mode nxml-outln nxml-rap sgml-mode facemenu nxml-util nxml-enc
xmltok make-mode flymake compile view python project org-indent oc-basic
org-element org-persist org-id org-element-ast inline avl-tree generator
ol-eww eww vtable url-queue mm-url ol-rmail ol-mhe ol-irc ol-info
ol-gnus nnselect ol-docview doc-view filenotify jka-compr image-mode
exif ol-bibtex bibtex ol-bbdb ol-w3m ol-doi org-link-doi cus-start
gnus-icalendar org-capture org-refile org ob ob-tangle ob-ref ob-lob
ob-table ob-exp org-macro org-src ob-comint org-pcomplete pcomplete
comint ansi-osc ansi-color org-list org-footnote org-faces org-entities
noutline outline org-version ob-emacs-lisp ob-core ob-eval org-cycle
org-table ol org-fold org-fold-core org-keys oc org-loaddefs org-compat
org-macs format-spec mule-util on-screen macrostep-c cmacexp macrostep
vc-dir ewoc vc-hg vc-git diff-mode track-changes files-x vc-bzr vc-src
vc-sccs vc-svn vc-cvs vc-rcs log-view log-edit add-log pcvs-util vc
vc-dispatcher debbugs-browse bug-reference sh-script rx smie treesit
executable gnus-dired time battery desktop frameset exwm-randr xcb-randr
exwm exwm-input xcb-keysyms xcb-xkb exwm-manage exwm-floating xcb-cursor
xcb-render exwm-layout exwm-workspace exwm-core xcb-ewmh xcb-icccm xcb
xcb-xproto xcb-types xcb-debug server ef-themes
modus-operandi-tinted-theme modus-themes zone speed-type dash thingatpt
url-http url-auth url-gw nsm compat ytdious ring mpdired transmission
color calc-bin calc-ext calc calc-loaddefs rect calc-macs supercite regi
ebdb-gnus gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime gnutls
dig gnus-sum shr pixel-fill kinsoku url-file svg dom gnus-group
gnus-undo gnus-start gnus-dbus dbus xml gnus-cloud nnimap nnmail
mail-source utf7 nnoo parse-time iso8601 gnus-spec gnus-int gnus-range
gnus-win ebdb-message message yank-media puny rfc822 mml mml-sec epa
derived epg rfc6068 epg-config mm-decode mm-bodies mm-encode mail-parse
rfc2231 gmm-utils mailheader ebdb-mua ebdb-com crm ebdb-format ebdb
mailabbrev eieio-opt speedbar ezimage dframe find-func eieio-base
timezone icalendar gnus nnheader gnus-util text-property-search
time-date range sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr
mail-utils erlang-start idlwave idlwave-menus idlw-menus
idlwave-bindings idlw-bindings idlwave-routine idlw-routine idlwave-scan
idlw-scan idlwave-help idlw-help idlwave-complete idlw-complete
idlwave-variables idlw-variables skeleton cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs elec-pair
edmacro kmacro use-package-bind-key bind-key appt diary-lib
diary-loaddefs cal-menu calendar cal-loaddefs pcase dired-x dired-aux
dired dired-loaddefs use-package-core repeat easy-mmode cus-edit pp
cus-load wid-edit debbugs-autoloads ebdb-autoloads cl-extra help-mode
ef-themes-autoloads elpher-autoloads exwm-autoloads gnuplot-autoloads
hyperbole-autoloads kotl-autoloads hact set hhist idlwave-autoloads
notmuch-autoloads on-screen-autoloads osm-autoloads pdf-tools-autoloads
rust-mode-autoloads slime-autoloads warnings macrostep-autoloads
speed-type-autoloads info dash-autoloads sudo-edit-autoloads
svg-clock-autoloads tablist-autoloads transmission-autoloads
xelb-autoloads ytdious-autoloads package browse-url xdg url url-proxy
url-privacy url-expand url-methods url-history url-cookie
generate-lisp-file url-domsuf url-util mailcap url-handlers url-parse
auth-source cl-seq eieio eieio-core cl-macs icons password-cache json
subr-x map byte-opt gv bytecomp byte-compile url-vars cl-loaddefs cl-lib
rmc iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen 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 nadvice seq simple cl-generic indonesian philippine
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 abbrev obarray oclosure
cl-preloaded button loaddefs theme-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 kqueue lcms2 dynamic-setting system-font-setting
font-render-setting x-toolkit xinput2 x multi-tty move-toolbar
make-network-process tty-child-frames emacs)

Memory information:
((conses 16 1088108 444189) (symbols 48 62510 40)
 (strings 32 306562 9080) (string-bytes 1 9162158) (vectors 16 187546)
 (vector-slots 8 2554645 95895) (floats 8 682 1144)
 (intervals 56 20781 559) (buffers 992 142))

-- 
Manuel Giraud

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 77988 <at> debbugs.gnu.org
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Sat, 26 Apr 2025 16:18:37 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Date: Tue, 22 Apr 2025 16:12:45 +0200
> 
> I have a nasty bug with the following minimal recipe:
> 
>        - emacs -Q
>        - M-: (find-file "etc/images/gnus/gnus.svg")
>        - M-: (set-frame-parameter nil 'fullscreen 'fullboth)
>        - M-: (load-theme 'modus-operandi)
> 
> The image disappears (or is replaced by garbage) and I'm not able to
> open any other image afterward.  FWIW, it seems that this bug only shows
> on a lucid build.

Can anyone else reproduce this?  I couldn't (but I don't have access
to a system where I could build and run a lucid Emacs).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: manuel <at> ledu-giraud.fr
Cc: 77988 <at> debbugs.gnu.org
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Sat, 10 May 2025 12:31:59 +0300

Ping! Could someone please reproduce this?

> Cc: 77988 <at> debbugs.gnu.org
> Date: Sat, 26 Apr 2025 16:18:37 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> > Date: Tue, 22 Apr 2025 16:12:45 +0200
> > 
> > I have a nasty bug with the following minimal recipe:
> > 
> >        - emacs -Q
> >        - M-: (find-file "etc/images/gnus/gnus.svg")
> >        - M-: (set-frame-parameter nil 'fullscreen 'fullboth)
> >        - M-: (load-theme 'modus-operandi)
> > 
> > The image disappears (or is replaced by garbage) and I'm not able to
> > open any other image afterward.  FWIW, it seems that this bug only shows
> > on a lucid build.
> 
> Can anyone else reproduce this?  I couldn't (but I don't have access
> to a system where I could build and run a lucid Emacs).
> 
> 
> 
> 

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77988 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Wed, 14 May 2025 12:47:54 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

> Ping! Could someone please reproduce this?

Yep, i could reproduce this, I've noticed that reproducing this on a
Cairo build (with same build options) seems to fix it.

-- 
                                          - E.G via GNU Emacs and Org.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 77988 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Thu, 15 May 2025 09:10:39 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: manuel <at> ledu-giraud.fr,  77988 <at> debbugs.gnu.org
> Date: Wed, 14 May 2025 12:47:54 -0600
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Ping! Could someone please reproduce this?
> 
> Yep, i could reproduce this, I've noticed that reproducing this on a
> Cairo build (with same build options) seems to fix it.

Since Manuel explicitly says this is a Lucid-only issue, this is
expected.

Are you able to debug this to figure out why the problem happens in
the Lucid build?

Thanks.

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77988 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Thu, 15 May 2025 22:54:24 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Cc: manuel <at> ledu-giraud.fr,  77988 <at> debbugs.gnu.org
>> Date: Wed, 14 May 2025 12:47:54 -0600
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Ping! Could someone please reproduce this?
>> 
>> Yep, i could reproduce this, I've noticed that reproducing this on a
>> Cairo build (with same build options) seems to fix it.
>
> Since Manuel explicitly says this is a Lucid-only issue, this is
> expected.
>
> Are you able to debug this to figure out why the problem happens in
> the Lucid build?

Yes, I can. The problem is I don't know how to send the debugging
information here (also, where to put the breakpoint since this only
affects to svg/png images).

I don't have much experience debugging Emacs.

So i'm sending here some backtraces that i could do and can be useful:

--8<---------------cut here---------------start------------->8---
#0  svg_load (f=0xb80e68, img=0x101d350) at image.c:11945
        success_p = true
        file_name = {i = 0xafdbc4}
        base_uri = {i = 0xce7d54}

---

#0  lookup_image (f=0xb80e68, spec=..., face_id=0) at image.c:3625
        ascent = {i = 0x0}
        margin = {i = 0x0}
        relief_bound = 2147483647
        relief = {i = 0x0}
        bg = {i = 0x7fffffff6f20}
        len = 13
        img = 0x101d350
        hash = 2570549387003761551
        face = 0xbdfd20
        foreground = 0
        background = 16777215
        font_size = 15
        font_family = 0xa67310 "Adwaita Mono"
#1  0x000000000044b361 in handle_single_display_spec (it=0x7fffffff86d0, spec=..., object=..., overlay=..., position=0x7fffffff8820, bufpos=1, display_replaced=0, frame_window_p=true, enable_eval_p=true) at xdisp.c:6491
        count = {bytes = 256}
        retval = 1
        eob = 15549
        form = {i = 0x30}
        location = {i = 0x0}
        value = {i = 0x7ffff18d12d3}
        start_pos = {charpos = 1, bytepos = 1}
        itdata = 0x0
        valid_p = true
#2  0x00000000004493bd in handle_display_spec (it=0x7fffffff86d0, spec=..., object=..., overlay=..., position=0x7fffffff8820, bufpos=1, frame_window_p=true) at xdisp.c:5939
        replacing = 0
        enable_eval = true
#3  0x0000000000448edf in handle_display_prop (it=0x7fffffff86d0) at xdisp.c:5847
        propval = {i = 0x7ffff18d12d3}
        object = {i = 0xd0cfd5}
        overlay = {i = 0x0}
        position = 0x7fffffff8820
        bufpos = 1
        display_replaced = 0
        objwin = {i = 0xb8112d}
#4  0x0000000000444600 in handle_stop (it=0x7fffffff86d0) at xdisp.c:4159
        handled = HANDLED_NORMALLY
        handle_overlay_change_p = true
        p = 0x8cabc0 <it_props+32>

---

#0  handle_single_display_spec (it=0x7fffffff86d0, spec=..., object=..., overlay=..., position=0x7fffffff8820, bufpos=1, display_replaced=0, frame_window_p=true, enable_eval_p=true) at xdisp.c:6504
        retval = 1
        eob = 15549
        form = {i = 0x30}
        location = {i = 0x0}
        value = {i = 0x7ffff18d12d3}
        start_pos = {charpos = 1, bytepos = 1}
        itdata = 0x0
        valid_p = true
--8<---------------cut here---------------end--------------->8---


-- 
                                          - E.G via GNU Emacs and Org.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>, Alan Third
 <alan <at> idiocy.org>
Cc: 77988 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Fri, 16 May 2025 10:22:36 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: 77988 <at> debbugs.gnu.org,  manuel <at> ledu-giraud.fr
> Date: Thu, 15 May 2025 22:54:24 -0600
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> >> Cc: manuel <at> ledu-giraud.fr,  77988 <at> debbugs.gnu.org
> >> Date: Wed, 14 May 2025 12:47:54 -0600
> >> 
> >> Eli Zaretskii <eliz <at> gnu.org> writes:
> >> 
> >> > Ping! Could someone please reproduce this?
> >> 
> >> Yep, i could reproduce this, I've noticed that reproducing this on a
> >> Cairo build (with same build options) seems to fix it.
> >
> > Since Manuel explicitly says this is a Lucid-only issue, this is
> > expected.
> >
> > Are you able to debug this to figure out why the problem happens in
> > the Lucid build?
> 
> Yes, I can.

Thanks, adding Alan to the discussion, in case he has comments or
ideas.

> The problem is I don't know how to send the debugging
> information here (also, where to put the breakpoint since this only
> affects to svg/png images).

svg_load seems to be a good place for the latter.

As for sending debugging information: just post the GDB commands you
use and their output, as plain text.

> I don't have much experience debugging Emacs.
> 
> So i'm sending here some backtraces that i could do and can be useful:

Are these backtraces before or after the problematic display happened?

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77988 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>, manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Sat, 17 May 2025 00:17:17 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

>> The problem is I don't know how to send the debugging
>> information here (also, where to put the breakpoint since this only
>> affects to svg/png images).
>
> svg_load seems to be a good place for the latter.
>
> As for sending debugging information: just post the GDB commands you
> use and their output, as plain text.

Thanks, I'll do that next time I have time.

>> I don't have much experience debugging Emacs.
>> 
>> So i'm sending here some backtraces that i could do and can be useful:
>
> Are these backtraces before or after the problematic display happened?

Before (i guess).

The first one is just before exiting svg_load.
And the others are when the svg image is going to be displayed.

-- 
                                          - E.G via GNU Emacs and Org.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 77988 <at> debbugs.gnu.org, alan <at> idiocy.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Sat, 17 May 2025 10:38:19 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: Alan Third <alan <at> idiocy.org>,  77988 <at> debbugs.gnu.org,
>   manuel <at> ledu-giraud.fr
> Date: Sat, 17 May 2025 00:17:17 -0600
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Are these backtraces before or after the problematic display happened?
> 
> Before (i guess).
> 
> The first one is just before exiting svg_load.
> And the others are when the svg image is going to be displayed.

We need to see what happens when the image is displayed correctly, and
then compare that with what happens when it is displayed incorrectly.

I suspect that something is wrong with the image cache.  So we need to
look at the image cache in both situations described above.

Can you show the data in the image cache in both situations?  The
function Frecenter is useful for getting control to GDB when you need.
So:

  $ gdb ./emacs
  ...
  (gdb) break Frecenter
  (gdb) r -Q

Then inside Emacs visit the gnus.svg file and make the frame
fullscreen:

  M-: (find-file "etc/images/gnus/gnus.svg") RET
  M-: (set-frame-parameter nil 'fullscreen 'fullboth) RET

Then trigger the breakpoint by typing C-l.  Then:

  (gdb) p Vframe_list
  (gdb) xcar

The last command with show something like

  $9 = (struct frame *) 0x90d31e8

(the numbers will be different in your case).  Then show the image
cache of that frame:

  (gdb) p $9->image_cache

(where $9 should be the same number as GDB shows you in the previous
line).  Post the results here.  Then let Emacs continue

  (gdb) c

Then do the last step of the recipe:

  M-: (load-theme 'modus-operandi) RET

And, assuming that the image becomes corrupted, type C-l to get
control back to GDB, and show the image cache again:

  (gdb) p $9->image_cache

and post the results.  It would be interesting to see the differences,
if any.

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77988 <at> debbugs.gnu.org, alan <at> idiocy.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Mon, 19 May 2025 14:06:56 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Cc: Alan Third <alan <at> idiocy.org>,  77988 <at> debbugs.gnu.org,
>>   manuel <at> ledu-giraud.fr
>> Date: Sat, 17 May 2025 00:17:17 -0600
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> > Are these backtraces before or after the problematic display happened?
>> 
>> Before (i guess).
>> 
>> The first one is just before exiting svg_load.
>> And the others are when the svg image is going to be displayed.
>
> We need to see what happens when the image is displayed correctly, and
> then compare that with what happens when it is displayed incorrectly.
>
> I suspect that something is wrong with the image cache.  So we need to
> look at the image cache in both situations described above.
>
> Can you show the data in the image cache in both situations?  The
> function Frecenter is useful for getting control to GDB when you need.
> So:
>
>   $ gdb ./emacs
>   ...
>   (gdb) break Frecenter
>   (gdb) r -Q
>
> Then inside Emacs visit the gnus.svg file and make the frame
> fullscreen:
>
>   M-: (find-file "etc/images/gnus/gnus.svg") RET
>   M-: (set-frame-parameter nil 'fullscreen 'fullboth) RET
>
> Then trigger the breakpoint by typing C-l.  Then:
>
>   (gdb) p Vframe_list
>   (gdb) xcar
>
> The last command with show something like
>
>   $9 = (struct frame *) 0x90d31e8
>
> (the numbers will be different in your case).  Then show the image
> cache of that frame:
>
>   (gdb) p $9->image_cache
>
> (where $9 should be the same number as GDB shows you in the previous
> line).  Post the results here.  Then let Emacs continue
>
>   (gdb) c
>
> Then do the last step of the recipe:
>
>   M-: (load-theme 'modus-operandi) RET
>
> And, assuming that the image becomes corrupted, type C-l to get
> control back to GDB, and show the image cache again:
>
>   (gdb) p $9->image_cache
>
> and post the results.  It would be interesting to see the differences,
> if any.

I've followed all the steps, It doesn't seem that there are any
differences:

M-: (find-file "etc/images/gnus/gnus.svg")
M-: (set-frame-parameter nil 'fullscreen 'fullboth)
C-l

(gdb) p Vframe_list
$1 = {
  i = 0x7ffff185e2c3
}
(gdb) xcar
$2 = {
  i = 0xbd3a7d
}
(gdb) xframe
$3 = (struct frame *) 0xbd3a78
"gnus.svg - GNU Emacs at fedora"
(gdb) p $3->image_cache
$4 = (struct image_cache *) 0xc20740
(gdb) c
Continuing.

(After the svg was displayed incorrectly):
M-: (load-theme 'modus-operandi)
C-l

Thread 1 "emacs" hit Breakpoint 3, Frecenter (arg=..., redisplay=...) at window.c:6976
6976	  struct window *w = XWINDOW (selected_window);
(gdb) p $3->image_cache
$5 = (struct image_cache *) 0xc20740

-- 
                                          - E.G via GNU Emacs and Org.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 77988 <at> debbugs.gnu.org, alan <at> idiocy.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Tue, 20 May 2025 14:57:21 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: 77988 <at> debbugs.gnu.org,  alan <at> idiocy.org,  manuel <at> ledu-giraud.fr
> Date: Mon, 19 May 2025 14:06:56 -0600
> 
> I've followed all the steps, It doesn't seem that there are any
> differences:
> 
> M-: (find-file "etc/images/gnus/gnus.svg")
> M-: (set-frame-parameter nil 'fullscreen 'fullboth)
> C-l
> 
> (gdb) p Vframe_list
> $1 = {
>   i = 0x7ffff185e2c3
> }
> (gdb) xcar
> $2 = {
>   i = 0xbd3a7d
> }
> (gdb) xframe
> $3 = (struct frame *) 0xbd3a78
> "gnus.svg - GNU Emacs at fedora"
> (gdb) p $3->image_cache
> $4 = (struct image_cache *) 0xc20740
> (gdb) c
> Continuing.
> 
> (After the svg was displayed incorrectly):
> M-: (load-theme 'modus-operandi)
> C-l
> 
> Thread 1 "emacs" hit Breakpoint 3, Frecenter (arg=..., redisplay=...) at window.c:6976
> 6976	  struct window *w = XWINDOW (selected_window);
> (gdb) p $3->image_cache
> $5 = (struct image_cache *) 0xc20740

OK, so the image cache stays put.  But what about its contents?  To
see this, we first need to know the cache slot where this image is
stored.  Here's how:

After visiting the image, type C-l and define one additional
breakpoint:

  (gdb) break set_cursor_from_row
  (gdb) c

When you continue, this new breakpoint will break almost immediately.
In most cases, the first time it breaks is in the wrong window.
Here4's how to verify that:

  Thread 1 hit Breakpoint 3, set_cursor_from_row (w=0x90d35e8, row=0x10056c18,
      matrix=0x909fa88, delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:18363
  18363     struct glyph *glyph = row->glyphs[TEXT_AREA];
  (gdb) p w->contents
  $1 = XIL(0xa00000000907a4f0)
  (gdb) xbuffer
  $2 = (struct buffer *) 0x907a4f0
  0x9048bf0 " *Echo Area 1*"

The command "xbuffer" (and other commands I use below) are defined in
src/.gdbinit.  So if GDB says it doesn't know about that command, tell
it to read .gdbinit:

  (gdb) source /path/to/emacs/src/.gdbinit

and then repeat the command, which should now work.

As you see above, the first time the breakpoint breaks, Emacs is
redisplaying the echo-area, which is not what we want.  So continue
the program until the next time the breakpoint breaks:

  (gdb) c
  Continuing.

  Thread 1 hit Breakpoint 3, set_cursor_from_row (w=0x90d3408, row=0x100c2b50,
      matrix=0x1005cf80, delta=0, delta_bytes=0, dy=0, dvpos=0) at xdisp.c:18363
  18363     struct glyph *glyph = row->glyphs[TEXT_AREA];
  (gdb) p w->contents
  $3 = XIL(0xa0000000090c3d20)
  (gdb) xbuffer
  $4 = (struct buffer *) 0x90c3d20
  0x90491ec "gnus.svg"

And now we are in the correct window.  So:

  (gdb) n
  18364     struct glyph *end = glyph + row->used[TEXT_AREA];
  (gdb) pgrow
  TEXT: 2 glyphs
    0    0: IMAGE[25] slice=0,0,260,264 pos=1 w=260 a+d=132+132 MB
    1  260: CHAR[ ] pos=0 blev=0,btyp=B w=8 a+d=132+132 MB

This tells us that the first (and only) "display element" in the
(only) screen line of the window is an image, and "[25]" says that the
image's cache slot is 25.  (In your case, the slot number might be
different.)  Now:

  (gdb) p Vframe_list
  $7 = XIL(0xc000000009150100)
  (gdb) xcar
  $8 = 0xa0000000090d31e8
  (gdb) xframe
  $9 = (struct frame *) 0x90d31e8
  "gnus.svg - GNU Emacs at ELIZ-PC"
  (gdb) p $9->image_cache
  $10 = (struct image_cache *) 0x90b8cf8
  (gdb) p *$9->image_cache
  $11 = {
    buckets = 0x1005bfa0,
    images = 0x90ae788,
    size = 50,
    used = 26,
    refcount = 1,
    scaling_col_width = 10
  }
  (gdb) p *$9->image_cache->images[25]
  $12 = {
    timestamp = {
      tv_sec = 1747466321,
      tv_nsec = 665317000
    },
    pixmap = 0x840517f3,
    mask = 0x0,
    xform = {
      eM11 = 1,
      eM12 = 0,
      eM21 = 0,
      eM22 = 1,
      eDx = 0,
      eDy = 0
    },
    smoothing = true,
    colors = 0x0,
    ncolors = 0,
    background = 4294967295,
    face_foreground = 33554432,
    face_background = 50331647,
    face_font_size = 13,
    face_font_family = 0x100ea860 "Courier New",
    face_font_height = 16,
    face_font_width = 8,
    background_transparent = 0,
    background_valid = 1,
    background_transparent_valid = 0,
    width = 260,
    height = 264,
    scale = 1,
    corners = {0, 0, -1, 0},
    ascent = 50,
    spec = XIL(0xc0000000090fb4e0),
    dependencies = XIL(0xc0000000090fb030),
    relief = 0,
    hmargin = 0,
    vmargin = 0,
    type = 0xd750c0 <image_types>,
    load_failed_p = false,
    lisp_data = XIL(0),
    hash = 15697133349389086448,
    id = 25,
    next = 0x0,
    prev = 0x0
  }

Do this before and after the corruption, and let's see if the cached
image changes.  Notes:

  . the breakpoint in set_cursor_from_row gets hit very frequently, so
    disable it after you use it the first time (the command is
    "disable N" where N is the number of the breakpoint), then do
    whatever it takes to have the image display incorrectly, then
    enable the breakpoint ("enable N") after C-l
  . the cache slot of the image might change after it gets corrupted,
    so don't assume it's the same slot number, but instead look at
    what the "pgrow" command shows, and use that.

Thanks.

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

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77988 <at> debbugs.gnu.org, Po Lu <luangruo <at> yahoo.com>,
 Elijah Gabe Pérez <eg642616 <at> gmail.com>,
 manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Tue, 20 May 2025 21:58:26 +0100

On Fri, May 16, 2025 at 10:22:36AM +0300, Eli Zaretskii wrote:
> > From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> > Cc: 77988 <at> debbugs.gnu.org,  manuel <at> ledu-giraud.fr
> > Date: Thu, 15 May 2025 22:54:24 -0600
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > >> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> > >> Cc: manuel <at> ledu-giraud.fr,  77988 <at> debbugs.gnu.org
> > >> Date: Wed, 14 May 2025 12:47:54 -0600
> > >> 
> > >> Eli Zaretskii <eliz <at> gnu.org> writes:
> > >> 
> > >> > Ping! Could someone please reproduce this?
> > >> 
> > >> Yep, i could reproduce this, I've noticed that reproducing this on a
> > >> Cairo build (with same build options) seems to fix it.
> > >
> > > Since Manuel explicitly says this is a Lucid-only issue, this is
> > > expected.
> > >
> > > Are you able to debug this to figure out why the problem happens in
> > > the Lucid build?
> > 
> > Yes, I can.
> 
> Thanks, adding Alan to the discussion, in case he has comments or
> ideas.

I think it's an issue at the display end. As Elijah says, if Cairo is
enabled it doesn't happen.

Reverting commit 6ea69fc7340e48cf73df351a544c1d8946395b3d seems to
make the problem go away. Cairo doesn't use the x_composite_image
function. It looks like the destination parameter is not always valid.
I had a look and it's usually populated from FRAME_X_PICTURE (s->f)
but a quick investigation left me none-the-wiser as to where THAT is
set and why it might go bad.

-- 
Alan Third

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>
Cc: 77988 <at> debbugs.gnu.org, luangruo <at> yahoo.com, eg642616 <at> gmail.com,
 manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Wed, 21 May 2025 14:28:46 +0300

> Date: Tue, 20 May 2025 21:58:26 +0100
> From: Alan Third <alan <at> idiocy.org>
> Cc: Elijah Gabe Pérez <eg642616 <at> gmail.com>,
> 	77988 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr,
> 	Po Lu <luangruo <at> yahoo.com>
> 
> On Fri, May 16, 2025 at 10:22:36AM +0300, Eli Zaretskii wrote:
> > > From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> > > Cc: 77988 <at> debbugs.gnu.org,  manuel <at> ledu-giraud.fr
> > > Date: Thu, 15 May 2025 22:54:24 -0600
> > > 
> > > Eli Zaretskii <eliz <at> gnu.org> writes:
> > > 
> > > >> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> > > >> Cc: manuel <at> ledu-giraud.fr,  77988 <at> debbugs.gnu.org
> > > >> Date: Wed, 14 May 2025 12:47:54 -0600
> > > >> 
> > > >> Eli Zaretskii <eliz <at> gnu.org> writes:
> > > >> 
> > > >> > Ping! Could someone please reproduce this?
> > > >> 
> > > >> Yep, i could reproduce this, I've noticed that reproducing this on a
> > > >> Cairo build (with same build options) seems to fix it.
> > > >
> > > > Since Manuel explicitly says this is a Lucid-only issue, this is
> > > > expected.
> > > >
> > > > Are you able to debug this to figure out why the problem happens in
> > > > the Lucid build?
> > > 
> > > Yes, I can.
> > 
> > Thanks, adding Alan to the discussion, in case he has comments or
> > ideas.
> 
> I think it's an issue at the display end. As Elijah says, if Cairo is
> enabled it doesn't happen.
> 
> Reverting commit 6ea69fc7340e48cf73df351a544c1d8946395b3d seems to
> make the problem go away. Cairo doesn't use the x_composite_image
> function. It looks like the destination parameter is not always valid.
> I had a look and it's usually populated from FRAME_X_PICTURE (s->f)
> but a quick investigation left me none-the-wiser as to where THAT is
> set and why it might go bad.

Thanks.

Po Lu, could you please take a look at this, in case your commit has
some problem in the Lucid build?

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

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Alan Third <alan <at> idiocy.org>
Cc: 77988 <at> debbugs.gnu.org, Po Lu <luangruo <at> yahoo.com>,
 Eli Zaretskii <eliz <at> gnu.org>,
 Elijah Gabe Pérez <eg642616 <at> gmail.com>
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Wed, 21 May 2025 13:47:24 +0200

Alan Third <alan <at> idiocy.org> writes:

[...]

> I think it's an issue at the display end. As Elijah says, if Cairo is
> enabled it doesn't happen.
>
> Reverting commit 6ea69fc7340e48cf73df351a544c1d8946395b3d seems to
> make the problem go away. Cairo doesn't use the x_composite_image
> function. It looks like the destination parameter is not always valid.
> I had a look and it's usually populated from FRAME_X_PICTURE (s->f)
> but a quick investigation left me none-the-wiser as to where THAT is
> set and why it might go bad.

Thanks.  I confirm that reverting this patch fixes the issue.
-- 
Manuel Giraud

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77988 <at> debbugs.gnu.org, alan <at> idiocy.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Wed, 21 May 2025 22:58:38 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Cc: 77988 <at> debbugs.gnu.org,  alan <at> idiocy.org,  manuel <at> ledu-giraud.fr
>> Date: Mon, 19 May 2025 14:06:56 -0600

[...]

>
> OK, so the image cache stays put.  But what about its contents?  To
> see this, we first need to know the cache slot where this image is
> stored.  Here's how:
>
> After visiting the image, type C-l and define one additional
> breakpoint:
>
>   (gdb) break set_cursor_from_row
>   (gdb) c
>

[...]

> Do this before and after the corruption, and let's see if the cached
> image changes.  Notes:
>
>   . the breakpoint in set_cursor_from_row gets hit very frequently, so
>     disable it after you use it the first time (the command is
>     "disable N" where N is the number of the breakpoint), then do
>     whatever it takes to have the image display incorrectly, then
>     enable the breakpoint ("enable N") after C-l
>   . the cache slot of the image might change after it gets corrupted,
>     so don't assume it's the same slot number, but instead look at
>     what the "pgrow" command shows, and use that.

Fine,

This is the result before the image corruption:

(gdb) n
18364	  struct glyph *end = glyph + row->used[TEXT_AREA];
(gdb) pgrow
TEXT: 2 glyphs
  0    0: IMAGE[25] slice=0,0,260,264 pos=1 w=260 a+d=132+132 MB
  1  260: CHAR[ ] pos=0 blev=0,btyp=B w=9 a+d=132+132 MB

[...]

(gdb) p $7->image_cache
$8 = (struct image_cache *) 0xc86cc0
(gdb) p *$7->image_cache
$9 = {
  buckets = 0xace870,
  images = 0xbaf1c0,
  size = 50,
  used = 26,
  refcount = 1,
  scaling_col_width = 10
}

(gdb) p *$7->image_cache->images[25]
$10 = {
  timestamp = {
    tv_sec = 1747799910,
    tv_nsec = 355847956
  },
  pixmap = 20972097,
  mask = 0,
  ximg = 0x0,
  mask_img = 0x0,
  picture = 20972098,
  mask_picture = 0,
  original_width = 260,
  original_height = 264,
  colors = 0x0,
  ncolors = 0,
  background = 16777215,
  face_foreground = 0,
  face_background = 16777215,
  face_font_size = 15,
  face_font_family = 0x10e7e10 "Adwaita Mono",
  face_font_height = 20,
  face_font_width = 9,
  background_transparent = false,
  background_valid = true,
  background_transparent_valid = false,
  width = 260,
  height = 264,
  scale = 1,
  corners = {0, 0, -1, 0},
  ascent = 50,
  spec = {
    i = 0x7ffff180f743
  },
  dependencies = {
    i = 0x7ffff180e253
  },
  relief = 0,
  hmargin = 0,
  vmargin = 0,
  type = 0x849a80 <image_types+32>,
  load_failed_p = false,
  lisp_data = {
    i = 0x0
  },
  hash = 2639822920428639045,
  id = 25,
  next = 0x0,
  prev = 0x0
}

* (After the svg was displayed incorrectly):

(gdb) n
18364	  struct glyph *end = glyph + row->used[TEXT_AREA];
(gdb) pgrow
TEXT: 2 glyphs
  0    0: IMAGE[26] slice=0,0,260,264 pos=1 w=260 a+d=132+132 MB
  1  260: CHAR[ ] pos=0 blev=0,btyp=B w=9 a+d=132+132 MB

[...]

(gdb) p $17->image_cache
$18 = (struct image_cache *) 0xc86cc0
(gdb) p *$17->image_cache
$19 = {
  buckets = 0xace870,
  images = 0xbaf1c0,
  size = 50,
  used = 27,
  refcount = 1,
  scaling_col_width = 10
}
(gdb) p *$17->image_cache->images[25]
$20 = {
  timestamp = {
    tv_sec = 1747800104,
    tv_nsec = 6461903
  },
  pixmap = 20972097,
  mask = 0,
  ximg = 0x0,
  mask_img = 0x0,
  picture = 20972098,
  mask_picture = 0,
  original_width = 260,
  original_height = 264,
  colors = 0x0,
  ncolors = 0,
  background = 16777215,
  face_foreground = 0,
  face_background = 16777215,
  face_font_size = 15,
  face_font_family = 0x10e7e10 "Adwaita Mono",
  face_font_height = 20,
  face_font_width = 9,
  background_transparent = false,
  background_valid = true,
  background_transparent_valid = false,
  width = 260,
  height = 264,
  scale = 1,
  corners = {0, 0, -1, 0},
  ascent = 50,
  spec = {
    i = 0x7ffff180f743
  },
  dependencies = {
    i = 0x7ffff180e253
  },
  relief = 0,
  hmargin = 0,
  vmargin = 0,
  type = 0x849a80 <image_types+32>,
  load_failed_p = false,
  lisp_data = {
    i = 0x0
  },
  hash = 2639822920428639045,
  id = 25,
  next = 0x0,
  prev = 0x0
}

It doesn't seem to make much difference, I've tested reverting commit
6ea69fc and it seems it fixes this (as Alan said).

Also It seems this bug has been around since emacs 29.1.
-- 
                                          - E.G via GNU Emacs and Org.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>
Cc: 77988 <at> debbugs.gnu.org, alan <at> idiocy.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Thu, 22 May 2025 10:07:30 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: 77988 <at> debbugs.gnu.org,  alan <at> idiocy.org,  manuel <at> ledu-giraud.fr
> Date: Wed, 21 May 2025 22:58:38 -0600
> 
> * (After the svg was displayed incorrectly):
> 
> (gdb) n
> 18364	  struct glyph *end = glyph + row->used[TEXT_AREA];
> (gdb) pgrow
> TEXT: 2 glyphs
>   0    0: IMAGE[26] slice=0,0,260,264 pos=1 w=260 a+d=132+132 MB
            ^^^^^^^^^

Note that the display now uses image-cache slot 26, not 25.  So this:

> (gdb) p *$17->image_cache->images[25]

shows the wrong cache slot, slot 25 and not 26.

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

From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77988 <at> debbugs.gnu.org, alan <at> idiocy.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Thu, 22 May 2025 13:59:32 -0600

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
>> Cc: 77988 <at> debbugs.gnu.org,  alan <at> idiocy.org,  manuel <at> ledu-giraud.fr
>> Date: Wed, 21 May 2025 22:58:38 -0600
>> 
>> * (After the svg was displayed incorrectly):
>> 
>> (gdb) n
>> 18364	  struct glyph *end = glyph + row->used[TEXT_AREA];
>> (gdb) pgrow
>> TEXT: 2 glyphs
>>   0    0: IMAGE[26] slice=0,0,260,264 pos=1 w=260 a+d=132+132 MB
>             ^^^^^^^^^
>
> Note that the display now uses image-cache slot 26, not 25.  So this:
>
>> (gdb) p *$17->image_cache->images[25]
>
> shows the wrong cache slot, slot 25 and not 26.

Oops, then I'm sending the new results again:


Before the image corruption:

(gdb) xbuffer
$4 = (struct buffer *) 0xcc0610
0xc60448 "gnus.svg"
(gdb) pgrow
TEXT: 2 glyphs
  0    0: IMAGE[21] slice=0,0,260,264 pos=1 w=260 a+d=132+132 MB
  1  260: CHAR[ ] pos=0 blev=0,btyp=B w=9 a+d=132+132 MB
(gdb) p $7->image_cache
$8 = (struct image_cache *) 0xb96250
(gdb) p *$7->image_cache
$9 = {
  buckets = 0xbbd2f0,
  images = 0xb74700,
  size = 50,
  used = 22,
  refcount = 1,
  scaling_col_width = 10
}
(gdb) p *$7->image_cache->images[21]
$10 = {
  timestamp = {
    tv_sec = 1747943056,
    tv_nsec = 645609582
  },
  pixmap = 20972089,
  mask = 0,
  ximg = 0x0,
  mask_img = 0x0,
  picture = 20972090,
  mask_picture = 0,
  original_width = 260,
  original_height = 264,
  colors = 0x0,
  ncolors = 0,
  background = 16777215,
  face_foreground = 0,
  face_background = 16777215,
  face_font_size = 15,
  face_font_family = 0xbc6200 "Adwaita Mono",
  face_font_height = 20,
  face_font_width = 9,
  background_transparent = false,
  background_valid = true,
  background_transparent_valid = false,
  width = 260,
  height = 264,
  scale = 1,
  corners = {0, 0, -1, 0},
  ascent = 50,
  spec = {
    i = 0x7ffff4627b53
  },
  dependencies = {
    i = 0x7ffff4627673
  },
  relief = 0,
  hmargin = 0,
  vmargin = 0,
  type = 0x837600 <image_types+32>,
  load_failed_p = false,
  lisp_data = {
    i = 0x0
  },
  hash = 2639822920428634449,
  id = 21,
  next = 0x0,
  prev = 0x0
}
(gdb) c
Continuing.



After the image corruption:

(gdb) xbuffer
$14 = (struct buffer *) 0xcc0610
0xa1cda8 "gnus.svg"
(gdb) pgrow
TEXT: 2 glyphs
  0    0: IMAGE[22] slice=0,0,260,264 pos=1 w=260 a+d=132+132 MB
  1  260: CHAR[ ] pos=0 blev=0,btyp=B w=9 a+d=132+132 MB
(gdb) p $17->image_cache
$18 = (struct image_cache *) 0xb96250
(gdb) p *$17->image_cache
$19 = {
  buckets = 0xbbd2f0,
  images = 0xb74700,
  size = 50,
  used = 37,
  refcount = 1,
  scaling_col_width = 10
}
(gdb) p *$17->image_cache->images[22]
$20 = {
  timestamp = {
    tv_sec = 1747943218,
    tv_nsec = 523120572
  },
  pixmap = 20972350,
  mask = 0,
  ximg = 0x0,
  mask_img = 0x0,
  picture = 20972352,
  mask_picture = 0,
  original_width = 260,
  original_height = 264,
  colors = 0x0,
  ncolors = 0,
  background = 16777215,
  face_foreground = 0,
  face_background = 16777215,
  face_font_size = 15,
  face_font_family = 0x10942f0 "Adwaita Mono",
  face_font_height = 20,
  face_font_width = 9,
  background_transparent = false,
  background_valid = true,
  background_transparent_valid = false,
  width = 260,
  height = 264,
  scale = 1,
  corners = {0, 0, -1, 0},
  ascent = 50,
  spec = {
    i = 0x14fbfc3
  },
  dependencies = {
    i = 0x14fc273
  },
  relief = 0,
  hmargin = 0,
  vmargin = 0,
  type = 0x837600 <image_types+32>,
  load_failed_p = false,
  lisp_data = {
    i = 0x0
  },
  hash = 2639822939957394001,
  id = 22,
  next = 0x0,
  prev = 0x0
}


-- 
                                          - E.G via GNU Emacs and Org.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Elijah Gabe Pérez <eg642616 <at> gmail.com>,
 Po Lu <luangruo <at> yahoo.com>
Cc: 77988 <at> debbugs.gnu.org, alan <at> idiocy.org, manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Fri, 23 May 2025 09:42:02 +0300

> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> Cc: 77988 <at> debbugs.gnu.org,  alan <at> idiocy.org,  manuel <at> ledu-giraud.fr
> Date: Thu, 22 May 2025 13:59:32 -0600
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> >> Cc: 77988 <at> debbugs.gnu.org,  alan <at> idiocy.org,  manuel <at> ledu-giraud.fr
> >> Date: Wed, 21 May 2025 22:58:38 -0600
> >> 
> >> * (After the svg was displayed incorrectly):
> >> 
> >> (gdb) n
> >> 18364	  struct glyph *end = glyph + row->used[TEXT_AREA];
> >> (gdb) pgrow
> >> TEXT: 2 glyphs
> >>   0    0: IMAGE[26] slice=0,0,260,264 pos=1 w=260 a+d=132+132 MB
> >             ^^^^^^^^^
> >
> > Note that the display now uses image-cache slot 26, not 25.  So this:
> >
> >> (gdb) p *$17->image_cache->images[25]
> >
> > shows the wrong cache slot, slot 25 and not 26.
> 
> Oops, then I'm sending the new results again:

Thanks.  This part looks suspicious:

>   spec = {
>     i = 0x14fbfc3
>   },
>   dependencies = {
>     i = 0x14fc273
>   },

These are Lisp objects, and in the "good" case they were 64-bit
values:

>   spec = {
>     i = 0x7ffff4627b53
>   },
>   dependencies = {
>     i = 0x7ffff4627673
>   },

So it seems somehow the offending commit causes their truncation?  Or
maybe these Lisp objects were GC'ed (but how could that happen, when
all the images in the image cache are marked?).

Po Lu, would you please look into this soon?

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

From: Alan Third <alan <at> idiocy.org>
To: Eli Zaretskii <eliz <at> gnu.org>,
 Elijah Gabe Pérez <eg642616 <at> gmail.com>,
 77988 <at> debbugs.gnu.org, manuel <at> ledu-giraud.fr, Po Lu <luangruo <at> yahoo.com>
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Fri, 23 May 2025 21:34:43 +0100

On Tue, May 20, 2025 at 09:58:26PM +0100, Alan Third wrote:
> Reverting commit 6ea69fc7340e48cf73df351a544c1d8946395b3d seems to
> make the problem go away. Cairo doesn't use the x_composite_image
> function. It looks like the destination parameter is not always valid.
> I had a look and it's usually populated from FRAME_X_PICTURE (s->f)
> but a quick investigation left me none-the-wiser as to where THAT is
> set and why it might go bad.

In case it's helpful to someone else I'll note that I found this
comment in xterm.c:

      /* Unfortunately, we need to call x_drop_xrender_surfaces for
         _all_ ConfigureNotify events, otherwise we miss some and
         flicker.  Don't try to optimize these calls by looking only
         for size changes: that's not sufficient.  We miss some
         surface invalidations and flicker.  */

x_drop_xrender_surfaces resets FRAME_X_PICTURE(s->f).

My suspicion is that loading modus-operandi is causing some other sort
of event that's been missed that invalidates the surface. I've no idea
what that could be though, as far as I can tell modus-operandi just
sets colours.

Loading other themes doesn't seem to trigger the bug though.

-- 
Alan Third

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alan Third <alan <at> idiocy.org>, Po Lu <luangruo <at> yahoo.com>
Cc: 77988 <at> debbugs.gnu.org, alan <at> idiocy.org, eg642616 <at> gmail.com,
 manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Sat, 07 Jun 2025 11:11:10 +0300

Ping! Ping!  Po Lu, could you please look into this ASAP?

> Date: Fri, 23 May 2025 21:34:43 +0100
> From: Alan Third <alan <at> idiocy.org>
> 
> On Tue, May 20, 2025 at 09:58:26PM +0100, Alan Third wrote:
> > Reverting commit 6ea69fc7340e48cf73df351a544c1d8946395b3d seems to
> > make the problem go away. Cairo doesn't use the x_composite_image
> > function. It looks like the destination parameter is not always valid.
> > I had a look and it's usually populated from FRAME_X_PICTURE (s->f)
> > but a quick investigation left me none-the-wiser as to where THAT is
> > set and why it might go bad.
> 
> In case it's helpful to someone else I'll note that I found this
> comment in xterm.c:
> 
>       /* Unfortunately, we need to call x_drop_xrender_surfaces for
>          _all_ ConfigureNotify events, otherwise we miss some and
>          flicker.  Don't try to optimize these calls by looking only
>          for size changes: that's not sufficient.  We miss some
>          surface invalidations and flicker.  */
> 
> x_drop_xrender_surfaces resets FRAME_X_PICTURE(s->f).
> 
> My suspicion is that loading modus-operandi is causing some other sort
> of event that's been missed that invalidates the surface. I've no idea
> what that could be though, as far as I can tell modus-operandi just
> sets colours.
> 
> Loading other themes doesn't seem to trigger the bug though.
> 
> -- 
> Alan Third
> 

> Cc: 77988 <at> debbugs.gnu.org, alan <at> idiocy.org, manuel <at> ledu-giraud.fr
> Date: Fri, 23 May 2025 09:42:02 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> > Cc: 77988 <at> debbugs.gnu.org,  alan <at> idiocy.org,  manuel <at> ledu-giraud.fr
> > Date: Thu, 22 May 2025 13:59:32 -0600
> > 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> > 
> > >> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> > >> Cc: 77988 <at> debbugs.gnu.org,  alan <at> idiocy.org,  manuel <at> ledu-giraud.fr
> > >> Date: Wed, 21 May 2025 22:58:38 -0600
> > >> 
> > >> * (After the svg was displayed incorrectly):
> > >> 
> > >> (gdb) n
> > >> 18364	  struct glyph *end = glyph + row->used[TEXT_AREA];
> > >> (gdb) pgrow
> > >> TEXT: 2 glyphs
> > >>   0    0: IMAGE[26] slice=0,0,260,264 pos=1 w=260 a+d=132+132 MB
> > >             ^^^^^^^^^
> > >
> > > Note that the display now uses image-cache slot 26, not 25.  So this:
> > >
> > >> (gdb) p *$17->image_cache->images[25]
> > >
> > > shows the wrong cache slot, slot 25 and not 26.
> > 
> > Oops, then I'm sending the new results again:
> 
> Thanks.  This part looks suspicious:
> 
> >   spec = {
> >     i = 0x14fbfc3
> >   },
> >   dependencies = {
> >     i = 0x14fc273
> >   },
> 
> These are Lisp objects, and in the "good" case they were 64-bit
> values:
> 
> >   spec = {
> >     i = 0x7ffff4627b53
> >   },
> >   dependencies = {
> >     i = 0x7ffff4627673
> >   },
> 
> So it seems somehow the offending commit causes their truncation?  Or
> maybe these Lisp objects were GC'ed (but how could that happen, when
> all the images in the image cache are marked?).
> 
> Po Lu, would you please look into this soon?
> 
> 
> 
> 

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 77988 <at> debbugs.gnu.org, alan <at> idiocy.org, eg642616 <at> gmail.com,
 manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Sat, 28 Jun 2025 11:54:41 +0300

Ping! Ping! Ping!  Po Lu, please respond.

> Cc: 77988 <at> debbugs.gnu.org, alan <at> idiocy.org, eg642616 <at> gmail.com,
>  manuel <at> ledu-giraud.fr
> Date: Sat, 07 Jun 2025 11:11:10 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> Ping! Ping!  Po Lu, could you please look into this ASAP?
> 
> > Date: Fri, 23 May 2025 21:34:43 +0100
> > From: Alan Third <alan <at> idiocy.org>
> > 
> > On Tue, May 20, 2025 at 09:58:26PM +0100, Alan Third wrote:
> > > Reverting commit 6ea69fc7340e48cf73df351a544c1d8946395b3d seems to
> > > make the problem go away. Cairo doesn't use the x_composite_image
> > > function. It looks like the destination parameter is not always valid.
> > > I had a look and it's usually populated from FRAME_X_PICTURE (s->f)
> > > but a quick investigation left me none-the-wiser as to where THAT is
> > > set and why it might go bad.
> > 
> > In case it's helpful to someone else I'll note that I found this
> > comment in xterm.c:
> > 
> >       /* Unfortunately, we need to call x_drop_xrender_surfaces for
> >          _all_ ConfigureNotify events, otherwise we miss some and
> >          flicker.  Don't try to optimize these calls by looking only
> >          for size changes: that's not sufficient.  We miss some
> >          surface invalidations and flicker.  */
> > 
> > x_drop_xrender_surfaces resets FRAME_X_PICTURE(s->f).
> > 
> > My suspicion is that loading modus-operandi is causing some other sort
> > of event that's been missed that invalidates the surface. I've no idea
> > what that could be though, as far as I can tell modus-operandi just
> > sets colours.
> > 
> > Loading other themes doesn't seem to trigger the bug though.
> > 
> > -- 
> > Alan Third
> > 
> 
> > Cc: 77988 <at> debbugs.gnu.org, alan <at> idiocy.org, manuel <at> ledu-giraud.fr
> > Date: Fri, 23 May 2025 09:42:02 +0300
> > From: Eli Zaretskii <eliz <at> gnu.org>
> > 
> > > From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> > > Cc: 77988 <at> debbugs.gnu.org,  alan <at> idiocy.org,  manuel <at> ledu-giraud.fr
> > > Date: Thu, 22 May 2025 13:59:32 -0600
> > > 
> > > Eli Zaretskii <eliz <at> gnu.org> writes:
> > > 
> > > >> From: Elijah Gabe Pérez <eg642616 <at> gmail.com>
> > > >> Cc: 77988 <at> debbugs.gnu.org,  alan <at> idiocy.org,  manuel <at> ledu-giraud.fr
> > > >> Date: Wed, 21 May 2025 22:58:38 -0600
> > > >> 
> > > >> * (After the svg was displayed incorrectly):
> > > >> 
> > > >> (gdb) n
> > > >> 18364	  struct glyph *end = glyph + row->used[TEXT_AREA];
> > > >> (gdb) pgrow
> > > >> TEXT: 2 glyphs
> > > >>   0    0: IMAGE[26] slice=0,0,260,264 pos=1 w=260 a+d=132+132 MB
> > > >             ^^^^^^^^^
> > > >
> > > > Note that the display now uses image-cache slot 26, not 25.  So this:
> > > >
> > > >> (gdb) p *$17->image_cache->images[25]
> > > >
> > > > shows the wrong cache slot, slot 25 and not 26.
> > > 
> > > Oops, then I'm sending the new results again:
> > 
> > Thanks.  This part looks suspicious:
> > 
> > >   spec = {
> > >     i = 0x14fbfc3
> > >   },
> > >   dependencies = {
> > >     i = 0x14fc273
> > >   },
> > 
> > These are Lisp objects, and in the "good" case they were 64-bit
> > values:
> > 
> > >   spec = {
> > >     i = 0x7ffff4627b53
> > >   },
> > >   dependencies = {
> > >     i = 0x7ffff4627673
> > >   },
> > 
> > So it seems somehow the offending commit causes their truncation?  Or
> > maybe these Lisp objects were GC'ed (but how could that happen, when
> > all the images in the image cache are marked?).
> > 
> > Po Lu, would you please look into this soon?
> > 
> > 
> > 
> > 
> 
> 
> 
> 

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77988 <at> debbugs.gnu.org, Alan Third <alan <at> idiocy.org>, eg642616 <at> gmail.com,
 manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Sat, 28 Jun 2025 21:50:15 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Thanks.  This part looks suspicious:
>> 
>> >   spec = {
>> >     i = 0x14fbfc3
>> >   },
>> >   dependencies = {
>> >     i = 0x14fc273
>> >   },
>> 
>> These are Lisp objects, and in the "good" case they were 64-bit
>> values:
>> 
>> >   spec = {
>> >     i = 0x7ffff4627b53
>> >   },
>> >   dependencies = {
>> >     i = 0x7ffff4627673
>> >   },
>> 
>> So it seems somehow the offending commit causes their truncation?  Or
>> maybe these Lisp objects were GC'ed (but how could that happen, when
>> all the images in the image cache are marked?).
>> 
>> Po Lu, would you please look into this soon?

If these fields are an excerpt from a `struct image', I can't imagine
why my commit could have truncated these Lisp_Objects, as `Picture's are
only X identifiers that are transmitted over the display connection.
I'll try to reproduce the OP's issue ASAP, and as ever I regret the
delay.

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

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77988 <at> debbugs.gnu.org, alan <at> idiocy.org, eg642616 <at> gmail.com,
 manuel <at> ledu-giraud.fr
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Sat, 28 Jun 2025 22:17:28 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

>> > Thanks.  This part looks suspicious:
>> > 
>> > >   spec = {
>> > >     i = 0x14fbfc3
>> > >   },
>> > >   dependencies = {
>> > >     i = 0x14fc273
>> > >   },
>> > 
>> > These are Lisp objects, and in the "good" case they were 64-bit
>> > values:
>> > 
>> > >   spec = {
>> > >     i = 0x7ffff4627b53
>> > >   },
>> > >   dependencies = {
>> > >     i = 0x7ffff4627673
>> > >   },
>> > 
>> > So it seems somehow the offending commit causes their truncation?  Or
>> > maybe these Lisp objects were GC'ed (but how could that happen, when
>> > all the images in the image cache are marked?).

This proved to be a red herring.  I believe the real culprit should have
been resolved, namely, XRender surfaces were not being invalidated when
the windows to which they are attached were resized without occasioning
a matching reconfiguration of their parent windows, which is likelier on
X toolkit builds than elsewhere.

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

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Po Lu <luangruo <at> yahoo.com>
Cc: 77988 <at> debbugs.gnu.org, eg642616 <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
 alan <at> idiocy.org
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Sun, 29 Jun 2025 17:41:28 +0200

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

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> > Thanks.  This part looks suspicious:
>>> > 
>>> > >   spec = {
>>> > >     i = 0x14fbfc3
>>> > >   },
>>> > >   dependencies = {
>>> > >     i = 0x14fc273
>>> > >   },
>>> > 
>>> > These are Lisp objects, and in the "good" case they were 64-bit
>>> > values:
>>> > 
>>> > >   spec = {
>>> > >     i = 0x7ffff4627b53
>>> > >   },
>>> > >   dependencies = {
>>> > >     i = 0x7ffff4627673
>>> > >   },
>>> > 
>>> > So it seems somehow the offending commit causes their truncation?  Or
>>> > maybe these Lisp objects were GC'ed (but how could that happen, when
>>> > all the images in the image cache are marked?).
>
> This proved to be a red herring.  I believe the real culprit should have
> been resolved, namely, XRender surfaces were not being invalidated when
> the windows to which they are attached were resized without occasioning
> a matching reconfiguration of their parent windows, which is likelier on
> X toolkit builds than elsewhere.

Thanks Po Lu.  I can confirm that 987cd7012de fixes the issue for lucid
build with the following recipe:

     - M-: (find-file "etc/images/gnus/gnus.svg")
     _ M-: (set-frame-parameter nil 'fullscreen 'fullboth)
     - M-: (load-theme 'modus-operandi)

Why was it not triggered with, said, M-: (load-theme 'tango) is beyond
me.
-- 
Manuel Giraud

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: luangruo <at> yahoo.com, Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: 77988 <at> debbugs.gnu.org, alan <at> idiocy.org, eg642616 <at> gmail.com
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Sat, 05 Jul 2025 11:53:20 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  alan <at> idiocy.org,  77988 <at> debbugs.gnu.org,
>   eg642616 <at> gmail.com
> Date: Sun, 29 Jun 2025 17:41:28 +0200
> 
> Po Lu <luangruo <at> yahoo.com> writes:
> 
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> >>> > Thanks.  This part looks suspicious:
> >>> > 
> >>> > >   spec = {
> >>> > >     i = 0x14fbfc3
> >>> > >   },
> >>> > >   dependencies = {
> >>> > >     i = 0x14fc273
> >>> > >   },
> >>> > 
> >>> > These are Lisp objects, and in the "good" case they were 64-bit
> >>> > values:
> >>> > 
> >>> > >   spec = {
> >>> > >     i = 0x7ffff4627b53
> >>> > >   },
> >>> > >   dependencies = {
> >>> > >     i = 0x7ffff4627673
> >>> > >   },
> >>> > 
> >>> > So it seems somehow the offending commit causes their truncation?  Or
> >>> > maybe these Lisp objects were GC'ed (but how could that happen, when
> >>> > all the images in the image cache are marked?).
> >
> > This proved to be a red herring.  I believe the real culprit should have
> > been resolved, namely, XRender surfaces were not being invalidated when
> > the windows to which they are attached were resized without occasioning
> > a matching reconfiguration of their parent windows, which is likelier on
> > X toolkit builds than elsewhere.
> 
> Thanks Po Lu.  I can confirm that 987cd7012de fixes the issue for lucid
> build with the following recipe:
> 
>      - M-: (find-file "etc/images/gnus/gnus.svg")
>      _ M-: (set-frame-parameter nil 'fullscreen 'fullboth)
>      - M-: (load-theme 'modus-operandi)
> 
> Why was it not triggered with, said, M-: (load-theme 'tango) is beyond
> me.

Should this bug be closed now?

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

From: Manuel Giraud <manuel <at> ledu-giraud.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, 77988 <at> debbugs.gnu.org, alan <at> idiocy.org,
 eg642616 <at> gmail.com
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Sat, 05 Jul 2025 12:20:52 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

[...]

>> > This proved to be a red herring.  I believe the real culprit should have
>> > been resolved, namely, XRender surfaces were not being invalidated when
>> > the windows to which they are attached were resized without occasioning
>> > a matching reconfiguration of their parent windows, which is likelier on
>> > X toolkit builds than elsewhere.
>> 
>> Thanks Po Lu.  I can confirm that 987cd7012de fixes the issue for lucid
>> build with the following recipe:
>> 
>>      - M-: (find-file "etc/images/gnus/gnus.svg")
>>      _ M-: (set-frame-parameter nil 'fullscreen 'fullboth)
>>      - M-: (load-theme 'modus-operandi)
>> 
>> Why was it not triggered with, said, M-: (load-theme 'tango) is beyond
>> me.
>
> Should this bug be closed now?

From my point of view, yes it could be closed.
-- 
Manuel Giraud

Message #85 received at 77988-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Manuel Giraud <manuel <at> ledu-giraud.fr>
Cc: luangruo <at> yahoo.com, 77988-done <at> debbugs.gnu.org, alan <at> idiocy.org,
 eg642616 <at> gmail.com
Subject: Re: bug#77988: 31.0.50; No more images after fullscreen and load-theme
Date: Sat, 05 Jul 2025 13:38:47 +0300

> From: Manuel Giraud <manuel <at> ledu-giraud.fr>
> Cc: luangruo <at> yahoo.com,  alan <at> idiocy.org,  77988 <at> debbugs.gnu.org,
>   eg642616 <at> gmail.com
> Date: Sat, 05 Jul 2025 12:20:52 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> [...]
> 
> >> > This proved to be a red herring.  I believe the real culprit should have
> >> > been resolved, namely, XRender surfaces were not being invalidated when
> >> > the windows to which they are attached were resized without occasioning
> >> > a matching reconfiguration of their parent windows, which is likelier on
> >> > X toolkit builds than elsewhere.
> >> 
> >> Thanks Po Lu.  I can confirm that 987cd7012de fixes the issue for lucid
> >> build with the following recipe:
> >> 
> >>      - M-: (find-file "etc/images/gnus/gnus.svg")
> >>      _ M-: (set-frame-parameter nil 'fullscreen 'fullboth)
> >>      - M-: (load-theme 'modus-operandi)
> >> 
> >> Why was it not triggered with, said, M-: (load-theme 'tango) is beyond
> >> me.
> >
> > Should this bug be closed now?
> 
> >From my point of view, yes it could be closed.

Thanks, closing.

Previous Next

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