[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).
- bug#71274: 30.0.50; assertion failed: w->window_end_valid, in find_first_unchanged_at_end_row,
Daniel Clemente <=