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

Previous Next

Package: emacs;

Reported by: Daniel Clemente <n142857 <at> gmail.com>

Date: Thu, 30 May 2024 09:53:02 UTC

Severity: normal

Found in version 30.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Daniel Clemente <n142857 <at> gmail.com>
Cc: 71274 <at> debbugs.gnu.org
Subject: bug#71274: 30.0.50; assertion failed: w->window_end_valid, in find_first_unchanged_at_end_row
Date: Mon, 03 Jun 2024 21:14:56 +0300
> From: Daniel Clemente <n142857 <at> gmail.com>
> Date: Mon, 3 Jun 2024 17:50:47 +0000
> Cc: 71274 <at> 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.




This bug report was last modified 1 year and 42 days ago.

Previous Next


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