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

[martin rudalics]

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

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.

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

Thanks, martin