> Date: Wed, 11 Sep 2024 16:37:58 +0200 > Cc: n142...@gmail.com, 73...@debbugs.gnu.org > From: martin rudalics <rudal...@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.
