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

Previous Next

Full log

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?
> 
> 
> 
> 

Previous Next

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