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

Previous Next

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: Fri, 31 May 2024 14:11:49 +0300

> From: Daniel Clemente <n142857 <at> gmail.com>
> Date: Fri, 31 May 2024 10:08:18 +0000
> Cc: 71274 <at> debbugs.gnu.org
> 
> > However, find_first_unchanged_at_end_row is called from try_window_id:
> > > #3  0x00005555555de527 in try_window_id (w=0x5555622c4f68) at xdisp.c:22347
> > And that function already checked that w->window_end_valid is
> > non-zero, several dozens of lines before that:
> >     /* Verify that display wasn't paused.  */
> >     if (!w->window_end_valid)
> >       GIVE_UP (8);
> 
> Between this check (the one "several dozens of lines before that"),
> and the call to find_first_unchanged_at_end_row, something has the
> side effect of changing window_end_valid to false. In particular:
> 
> 
>   if (last_unchanged_at_beg_row)
>     {
>       /* Avoid starting to display in the middle of a character, a TAB
>      for instance.  This is easier than to set up the iterator
>      exactly, and it's not a frequent case, so the additional
>      effort wouldn't really pay off.  */
>       while ((MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (last_unchanged_at_beg_row)
>           || last_unchanged_at_beg_row->ends_in_newline_from_string_p)
>          && last_unchanged_at_beg_row > w->current_matrix->rows)
>     --last_unchanged_at_beg_row;
> 
>       if (MATRIX_ROW_ENDS_IN_MIDDLE_OF_CHAR_P (last_unchanged_at_beg_row))
>     GIVE_UP (17);
> 
>       if (! init_to_row_end (&it, w, last_unchanged_at_beg_row))
>     GIVE_UP (18);
> 
> 
> Before that last init_to_row_end, w->window_end_valid was true, and,
> after it, it was false.

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 is easy to add some band-aid without such an understanding, but
I'm not yet prepared to do that.)

> I saw it through fprintfs added before and after the line.
> It's not always like that; sometimes it just stays true all through. I
> still don't know the conditions to reproduce this, but I have seen
> this bug 4 or 5 times yesterday+today.
> 
> So it must be a side effect of init_to_row_end.

Yes, but where exactly in that function or the ones it calls?

> By the way, could this comment in try_window_id explain what is
> happening? Maybe this part needs to be moved earlier.

Maybe.  But I'd like to see a backtrace with some of those guilty
parties in the callstack, before I do that.

Previous Next

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