GNU bug report logs -
#77988
31.0.50; No more images after fullscreen and load-theme
Previous Next
Reported by: Manuel Giraud <manuel <at> ledu-giraud.fr>
Date: Tue, 22 Apr 2025 14:14:02 UTC
Severity: normal
Found in version 31.0.50
Done: Eli Zaretskii <eliz <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
Message #65 received at 77988 <at> debbugs.gnu.org (full text, mbox):
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?
> >
> >
> >
> >
>
>
>
>
This bug report was last modified 7 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.