bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel Clemente
Subject: bug#71274: 30.0.50; assertion failed: w->window_end_valid, in find_first_unchanged_at_end_row
Date: Mon, 3 Jun 2024 17:50:47 +0000

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]