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: Wed, 11 Sep 2024 16:37:58 +0200
> Cc: n142857@gmail.com, 73022@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 
>  >>   > For instance, Eli recently added this code (dispnew.c):
>  >>   >
>  >>   >    /* This should never happen, but evidently sometimes does if one
>  >>   >       resizes the frame quickly enough.  Prevent aborts in cmcheckmagic.  */
>  >>   >    if (vpos >= FRAME_TOTAL_LINES (f))
>  >>   >      return;
>  >>   >
>  >>   > But this is checking the *frame*.  Later, the assertion in
>  >>   > cmcheckmagic will be made about the *terminal*.
>  >>
>  >> Right.  This should probably be
>  >>
>  >>     if (FRAME_TERMCAP_P (f) && vpos >= FrameRows (FRAME_TTY (f)))
>  >>       return;
>  >
>  > That code is in update_frame_line, which is used only for TTY frames
>  > and uses frame glyph matrices.  IOW, it updates the entire frame as a
>  > single large window.  In addition, on a TTY terminal there's only one
>  > frame visible at any given time, and only that one frame is being
>  > redrawn, ever.
>  >
>  > Given the above, why is that code incorrect?
> 
> It _might_ be incorrect when we allow FRAME_TOTAL_LINES (f) to exceed
> FrameRows (FRAME_TTY (f)) because we refuse to shrink a frame below some
> height.  That's why I used the term "probably".  If I knew what that
> code does in all consequences, I could tell you more.  But I don't know.

If FRAME_TOTAL_LINES is different from FrameRows at that spot, it's a
bug, isn't it?

The reason I didn't want to depend on FrameRows is that it might be
modified by a signal handler, and I couldn't convince myself that they
will always be in sync when we get to that spot.  FRAME_TOTAL_LINES is
the result of us adjusting the frame size when it's safe to do so, and
it sounded like a better idea to me.

>  >> And it's not about resizing frames "quickly".  Here I can crash it in a
>  >> very slow fashion too.
>  >
>  > Good for you, but my comment describes the situation in which I saw
>  > that particular problem.  As I already said, I can never crash Emacs
>  > if I resize the terminal emulator window slowly.
> 
> And as I already said I can crash Emacs reliably if I slowly shrink the
> window, slowly expand it again, precisely at the moment it should reshow
> the minibuffer window.  You can ask me any question about the state of
> the frame and its windows at the time of the crash.

I still don't understand what is supposed to happen when we shrink the
frame to less lines/columns than the minimum window dimensions we
allow.  Also, I'd be happier if you could describe the sequence of
events that lead to frame and window resizing following a SIGWINCH.

>  > Most probably because the terminal driver simply ignores such writes.
>  > AFAIU, the assertion there is not because of the terminal, it is there
>  > to catch Emacs bugs.
> 
> Then tell us how to catch it.  I'm already out of ideas.

Maybe later, when I have more time to think about this.