From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: n142857@gmail.com, 73022@debbugs.gnu.org
Subject: bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size
Date: Wed, 11 Sep 2024 18:06:39 +0300 [thread overview]
Message-ID: <86wmjinsao.fsf@gnu.org> (raw)
In-Reply-To: <0e489c29-8274-4610-835a-b01c66a48fca@gmx.at> (message from martin rudalics on Wed, 11 Sep 2024 16:37:58 +0200)
> 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.
next prev parent reply other threads:[~2024-09-11 15:06 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-09-04 6:09 bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size Daniel Clemente
[not found] ` <handler.73022.B.172543028723315.ack@debbugs.gnu.org>
2024-09-04 6:25 ` bug#73022: Acknowledgement (31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size) Daniel Clemente
2024-09-04 7:28 ` bug#73022: 31.0.50; Crash in build_frame_matrix_from_leaf_window after C-x 2 and reducing terminal size martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-04 12:21 ` Eli Zaretskii
2024-09-04 13:23 ` Eli Zaretskii
2024-09-05 8:18 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-05 9:19 ` Eli Zaretskii
2024-09-05 14:46 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-05 14:58 ` Eli Zaretskii
2024-09-05 15:48 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-05 16:05 ` Eli Zaretskii
2024-09-05 16:30 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-05 16:58 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-05 18:41 ` Eli Zaretskii
2024-09-05 18:15 ` Eli Zaretskii
2024-09-08 11:07 ` Daniel Clemente
2024-09-08 14:36 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-05 8:18 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-05 9:18 ` Eli Zaretskii
2024-09-05 14:45 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-05 15:10 ` Eli Zaretskii
2024-09-05 16:27 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-08 11:08 ` Daniel Clemente
2024-09-08 11:31 ` Eli Zaretskii
2024-09-08 14:58 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-10 17:43 ` Daniel Clemente
2024-09-11 8:07 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-11 12:22 ` Eli Zaretskii
2024-09-11 14:37 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-11 15:06 ` Eli Zaretskii [this message]
2024-09-12 9:49 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-08 11:09 ` Daniel Clemente
2024-09-08 14:43 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-08 15:32 ` Eli Zaretskii
2024-09-08 17:01 ` martin rudalics via Bug reports for GNU Emacs, the Swiss army knife of text editors
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86wmjinsao.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=73022@debbugs.gnu.org \
--cc=n142857@gmail.com \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.