bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size

[Eli Zaretskii <eliz@gnu.org>]

> Date: Thu, 5 Sep 2024 16:45:52 +0200
> Cc: n142857@gmail.com, 73022@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  >> If so, then this violation might be caused by the fact that we
>  >> (1) did resize windows according to the new sizes but (2) did not update
>  >> the frame sizes accordingly.
>  >
>  > Can you elaborate on how this could be possible?  I always thought we
>  > first allocate the frame matrices, and then the window matrices (by
>  > suballocating them from the frame matrices).  Am I mistaken?
> 
> But if glyph_row_slice_p (window_row, frame_row) fails, something else
> must have invalidated that.  I made that change here more than three
> years ago and I can neither remember whether an assertion violation made
> me do it or a crash nor why I did chose a term like "congruent" in the
> comment.

I agree with the theory that the frame matrices were reallocated
whereas the window matrices weren't, or the other way around.  I just
don't understand how it could have happened, given the code we have.

I noticed that causing this assertion to fail is not very easy.  For
example, if I drag the terminal emulator window one line at a time, I
can never cause it, even if I get to frame sizes that are much smaller
than the minimum we need for 2 windows.  Somehow, I need to drag the
frame so it resizes by several lines and/or columns.  Not sure why.

> One possibility I cannot exclude is that adjust_frame_size tries to
> resize windows, that step (silently) fails in window_resize_check, the
> old values stay in place but the new frame sizes are applied by
> adjust_frame_size.  But precisely this scenario cannot be healed by my
> patch so it's unlikely that it was the cause for the problem I
> experienced back then.

What is supposed to happen, with the current code, when the frame is
resized to less than the minimum dimensions we allow?  Shouldn't we
disallow/refuse such resizes?  And if we don't refuse, what will
happen to the windows?  E.g., if the frame is not tall enough to show
the menu bar, the two mode lines, the mini-window, and at least one
line for each of the two windows, what should I expect to see on
display?

>  > Moving code in adjust_frame_glyphs could affect the assertion if the
>  > assertion was being hit while adjust_frame_glyphs is still being
>  > executed.  But that is not the case, so I don't understand how moving
>  > some code in adjust_frame_glyphs without changing it could affect the
>  > assertion violation.  I'm probably missing something.
> 
> I'm still too dense to understand what "Moving code" and "moving some
> code" could mean in this context.  If you have enough patience left,
> please elaborate.

Taking some code and moving it to another place in the same function
can only affect what's going on in that function and the functions it
calls.  For example, if you had

   foo ();
   bar ();
   baz ();

and then you move the call to baz to be before the call to bar, like
this:

   foo ();
   baz ();
   bar ();

then I can understand why bar and its subroutines are affected.  But
once we are done with this code, all the 3 calls have been made, and
the order in which they were made can hardly matter for the code which
runs after that, right?

So if the crash was inside the call to bar, then I could understand
how moving the call to baz before it could affect the crash.  But the
backtrace from the assertion violation didn't show adjust_frame_glyphs
anywhere on the call-stack, so I don't understand how simply
rearranging code inside adjust_frame_glyphs could change something
_outside_ it.