From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs 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 Message-ID: <86wmjinsao.fsf@gnu.org> References: <86le07624j.fsf@gnu.org> <60579ab6-db81-4f6e-b281-0cee03dc3b82@gmx.at> <86cyli4fxj.fsf@gnu.org> <86seue2l2b.fsf@gnu.org> <2d8e4603-5ea6-41e9-abfe-461392f717db@gmx.at> <4c3591f1-7c26-489f-ba68-8586e98cd99e@gmx.at> <861q1qpehg.fsf@gnu.org> <0e489c29-8274-4610-835a-b01c66a48fca@gmx.at> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20233"; mail-complaints-to="usenet@ciao.gmane.io" Cc: n142857@gmail.com, 73022@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 11 17:15:46 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1soP4L-00055m-Hm for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 11 Sep 2024 17:15:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1soOyX-0008L1-Sf; Wed, 11 Sep 2024 11:09:49 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1soOvp-00063s-0t for bug-gnu-emacs@gnu.org; Wed, 11 Sep 2024 11:07:00 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1soOvn-0000tr-Fg for bug-gnu-emacs@gnu.org; Wed, 11 Sep 2024 11:06:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=bkmtF2qRgzjOo/DFqGQjui/IwG1wnk2NI4ZFNtAGBYU=; b=oMp9AupyGD2qaL6TCzvQRDvtag4Upq9Ne9neGbekaV/qOAMdKp/gJB9n+DdeHvc1HTeDTA3X639qnfv9Vva/BYYhxgqFIfR77d1JOviCTd4VjHvM/KpHFJY4Z9Eyuixu30ExJ1CK7uZK4sRWKXosO2HzAGBPYIboUmpSOPCGH821yvZ8ZmUy41NIisVm6x2nXU9zTHcRaeI3TEiOhcBF8Wwuavecj6dQ6APsfLYIsYL+/Mjoqwl+vsQ5z5uK57GGQ/lJQStTIdOv6ko01tv8YVSfO0eYEX3jfPCF9shJ+cBeSG1GgfmKxE2SsmIBHcc/jcPas+QqwHlvQ+o/qsoznQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1soOvt-0007XJ-Rj for bug-gnu-emacs@gnu.org; Wed, 11 Sep 2024 11:07:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Sep 2024 15:07:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 73022 X-GNU-PR-Package: emacs Original-Received: via spool by 73022-submit@debbugs.gnu.org id=B73022.172606722028962 (code B ref 73022); Wed, 11 Sep 2024 15:07:01 +0000 Original-Received: (at 73022) by debbugs.gnu.org; 11 Sep 2024 15:07:00 +0000 Original-Received: from localhost ([127.0.0.1]:39399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soOvs-0007X4-6s for submit@debbugs.gnu.org; Wed, 11 Sep 2024 11:07:00 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:40266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1soOvp-0007Wq-Q3 for 73022@debbugs.gnu.org; Wed, 11 Sep 2024 11:06:58 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1soOvd-0000tQ-0P; Wed, 11 Sep 2024 11:06:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=bkmtF2qRgzjOo/DFqGQjui/IwG1wnk2NI4ZFNtAGBYU=; b=JOsR/zsZ68vW DYql6xFGqR5OXS4AusUil7FQaxNeDDUfpic7wxbLnvwYnV0fS1fszmsK8vtmldqxMHRG8WLm9keDw WyO+OxxjFwvoOY+7UoxO4Gor21L4e2lkxx3ASCqONqIwCkMdW1PXqTsvpa4Be0WNgjftG1DVz7nrb p1hwX6LJbXYvJtlEYE85wPecfMMRUK9DYDF0u3DqCDHKthyG86aVTi+RBzkRJAlbw+Zq/CMOOUQx3 jBT5RJEBRinVbZmieXj1CIu/l173HAbHLK3Ldf3Zi+xhyDqR0VmFxql9k8+mBvWVCqjASKaoGx84M xGqahn9cPupwTmldo7HeQA==; In-Reply-To: <0e489c29-8274-4610-835a-b01c66a48fca@gmx.at> (message from martin rudalics on Wed, 11 Sep 2024 16:37:58 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:291606 Archived-At: > Date: Wed, 11 Sep 2024 16:37:58 +0200 > Cc: n142857@gmail.com, 73022@debbugs.gnu.org > From: martin rudalics > > >> > 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.