bug#71274: 30.0.50; assertion failed: w->window_end_valid, in find_first_unchanged_at_end_row

[Daniel Clemente <n142857@gmail.com>]

Thanks, well, I'm not seeing these errors anymore. I don't have a
formula to reproduce the bug, but I trust the patch will help and this
bug can be closed.

I don't much knowledge about try_window_id. Could this change create
new situations in which a window isn't fully redisplayed but it
should?
I saw a redisplay issue after resizing the window (mangled text) but I
don't think it's related to this bug because I placed a breakpoint on
your new code and it didn't run.  I posted some details at 71289.









On Mon, 3 Jun 2024 at 18:15, Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Daniel Clemente <n142857@gmail.com>
> > Date: Mon, 3 Jun 2024 17:50:47 +0000
> > Cc: 71274@debbugs.gnu.org
> >
> > > Thanks, but please find where it changes inside the call to
> > > init_to_row_end, because I couldn't see anything obvious in the code
> > > involved in that call.  There's some factor at work here that we need
> > > to identify and understand.
> >
> > It happens (window_end_valid becoming false) inside init_iterator,  in
> > init_from_display_pos (called init_to_row_end). Here:
> >
> >   /* Keep in mind: the call to reseat in init_iterator skips invisible
> >      text, so we might end up at a position different from POS.  This
> >      is only a problem when POS is a row start after a newline and an
> >      overlay starts there with an after-string, and the overlay has an
> >      invisible property.  Since we don't skip invisible text in
> >      display_line and elsewhere immediately after consuming the
> >      newline before the row start, such a POS will not be in a string,
> >      but the call to init_iterator below will move us to the
> >      after-string.  */
> >  init_iterator (it, w, charpos, bytepos, NULL, DEFAULT_FACE_ID);
> >
> >
> > Inside init_iterator, window_end_valid becomes false during this code
> > (i.e. it was true just before, and false just after):
> >
> >   /* If face attributes have been changed since the last redisplay,
> >      free realized faces now because they depend on face definitions
> >      that might have changed.  Don't free faces while there might be
> >      desired matrices pending which reference these faces.  */
> >   if (!inhibit_free_realized_faces)
> >     {
> >       if (face_change)
> >     {
> >       face_change = false;
> >       XFRAME (w->frame)->face_change = 0;
> >       free_all_realized_faces (Qnil);
> >     }
> >       else if (XFRAME (w->frame)->face_change)
> >     {
> >       XFRAME (w->frame)->face_change = 0;
> >       free_all_realized_faces (w->frame);
> >     }
> >     }
> >
> > I don't know yet which branch runs or what happens inside
> > free_all_realized_faces, since I didn't see this crash recently.
> >
> > Does this give any hint about how window_end_valid could become false?
>
> Yes, it does, thanks.  I installed a fix which hopefully plugs this.
>
> > In next tests I'll run with the latest git version, including your
> > recent commit eb9afd558ec (which I know is for something different
> > —SIGWINCH— but who knows, maybe it was related to this bug).
>
> I don't think so.