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

[Daniel Clemente <n142857@gmail.com>]

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

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).