From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Clemente 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: Tue, 10 Sep 2024 17:43:57 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="27663"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 73022@debbugs.gnu.org, Eli Zaretskii To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Sep 10 19:46:31 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 1so4wg-00073H-VJ for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 10 Sep 2024 19:46:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1so4wK-0005w7-NG; Tue, 10 Sep 2024 13:46:09 -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 1so4wI-0005sQ-Ok for bug-gnu-emacs@gnu.org; Tue, 10 Sep 2024 13:46:06 -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 1so4w8-0005IA-Og for bug-gnu-emacs@gnu.org; Tue, 10 Sep 2024 13:46:06 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:From:In-Reply-To:References:MIME-Version:To:Subject; bh=p6WDnKGDCyjk05NRZA+pWOKu2FiqrZWkui4QJEG2L2I=; b=WNTamUPpDOfRJFKKaAas05DVGH6UC6bmqgglAFjeE9upaoY6wu5Zp6lCIXJTNOnJW4hrJXottWa5ICbM8l6NUExziRdSpAH39EMjMjRKpsTxwIPvrq9Ua9DV2ixejJVgcVXwfASOYw96PXx0o2cl9D8dkuuKpEspMCYKVyZZ9phbw9ty9SUWgL6ydTT3+JGAYZLKbplMg2/rds6JXosCwHri6obknPFzxQIz1U+KsgU8W/XxVluCLqlcumLnT/Gev/Xr8i8JtbpRPo47trAtLvW19SywfC2atTkz6qFJ6uYT6/G8gbXCzI2M+nQMpkr2bN/7fSBGonjOyo2QRirNxA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1so4wD-0000rx-VN for bug-gnu-emacs@gnu.org; Tue, 10 Sep 2024 13:46:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Daniel Clemente Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 10 Sep 2024 17:46: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.17259903373293 (code B ref 73022); Tue, 10 Sep 2024 17:46:01 +0000 Original-Received: (at 73022) by debbugs.gnu.org; 10 Sep 2024 17:45:37 +0000 Original-Received: from localhost ([127.0.0.1]:36977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1so4vp-0000r2-5u for submit@debbugs.gnu.org; Tue, 10 Sep 2024 13:45:37 -0400 Original-Received: from mail-ua1-f48.google.com ([209.85.222.48]:56764) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1so4vn-0000qp-49 for 73022@debbugs.gnu.org; Tue, 10 Sep 2024 13:45:35 -0400 Original-Received: by mail-ua1-f48.google.com with SMTP id a1e0cc1a2514c-846bcf3677dso1595629241.1 for <73022@debbugs.gnu.org>; Tue, 10 Sep 2024 10:45:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1725990264; x=1726595064; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=p6WDnKGDCyjk05NRZA+pWOKu2FiqrZWkui4QJEG2L2I=; b=mWpDkWMt/f+XDub6AbmMKI3HLxzLHJOk5+7XPpnWrQDFJxPFXKJzpcRlSmU3aN9b6i 6KyHGe/eheFWURbvFXiy8FrV+xurTicfTMjnvDrx6CvcIZYntxNi90qlpjx/88Dj2bkC +zmq21LUUmEOzbn8CsWSiGepexPsEhHZq+NIVDkTjbWahv1gW5iC2UuYREokQSToCysn 5VHPJ1Oh4LkYK01jRjHBG0fDdhMrFb+Uj31cVdmLmEU0yI9ASELDSFrxmYtp1FGm811e met7T93zMvEq3YPS9RfvCgxr9VS/gkZ1k6+YJioDIUk2h0OwlBITBfBngYv4SKJo7lQp aYuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1725990264; x=1726595064; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=p6WDnKGDCyjk05NRZA+pWOKu2FiqrZWkui4QJEG2L2I=; b=qGqi7TFbSvGAViOvmV1TKhX+WTNVqwf7kFeVvGP8V9Rhj6Su6AkhsCDmSdewzAjn8j dfpeLD+ATrggMFC6HpdiKtGNSQzZZtglU5r+D06lH0DbUWA0UYGw8fBSixUfPdYLK70t uXPFBw6aidrnFqCMTPz6k4vEpkWRf+ryo+dwgk6mIZAkJiLTnSMdKiPIBpGZhjnuI5JT KjA7CA/LAdeePwwt/iB83tohH7d1LInmTpncQZEfCncGZjNcdMhMhmubxB6aMtzrYrSk LzMdVQErRrhkyIjAJfqcKUjmYtacsRMUMHwq9xz28KFlUoAqYRe7QWDYNhG+wvkwxjKf gdVQ== X-Forwarded-Encrypted: i=1; AJvYcCVEd/wd5LX40OP6T6oTALobVUsKxKLLO2cvMtoVRZY97H5QXlykzqpIYweH6lekHWEnPESTIw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzzuDtchTbAnQ5bHS8FfL3VouZX1lvLSMS3lgd4TwwW3PN3uzux UEEN1Ud+JBn0kWOYiIGkA25eLK3+9PfU3YSKrzPZzVDP1Q+Ti14cL6v9rWV/Hfh96oTvvQ5Mjt8 reqy4HcJUm86NmQwh1P68M6Z131k= X-Google-Smtp-Source: AGHT+IFXUtprgJUA4mCupzYlRyUSi6NB0GTcaGFzG5CXUcsg8PLqh96SMGmct5EiRm3H9Bo3gPy1uzrG9Up8CtrPG0U= X-Received: by 2002:a05:6102:f0b:b0:48f:4a50:233e with SMTP id ada2fe7eead31-49bde2647b5mr16641846137.21.1725990264299; Tue, 10 Sep 2024 10:44:24 -0700 (PDT) In-Reply-To: <2d8e4603-5ea6-41e9-abfe-461392f717db@gmx.at> 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:291575 Archived-At: > Please try the attached diff (from my heavily edited copy of master, if > it doesn't apply cleanly, complain immediately rather than messing up > your Emacs). It should fix two silly bugs in window.el that make a > frame's safe minimum size much too large and includes the fix I proposed > earlier here. It applies well; thanks. By the way, (window-min-size) still answers 4 (with and without your patch)= . Emacs feels a bit "stronger" in the C-x 2 scenario, meaning that it survives shrinking+enlarging the terminal, but it still crashes sometimes. But it also crashes in a new situation: just by shrinking the normal/initial/unsplit frame, i.e. without needing to do C-x 2. It didn't crash before, so the patch doesn't make the whole Emacs more stable yet. Without doing C-x 2: #4 0x00005555556c3016 in emacs_abort () at sysdep.c:2391 #5 0x000055555566d36f in cmcheckmagic (tty=3D0x55555608fa80) at cm.c:122 #6 0x0000555555671b1b in tty_write_glyphs (f=3D0x555556012ff0, string=3D0x7ffff0f4ec10, len=3D80) at term.c:831 #7 0x000055555567c11d in write_glyphs (f=3D0x555556012ff0, string=3D0x7ffff0f4dd10, len=3D80) at terminal.c:164 #8 0x0000555555591b60 in update_frame_line (f=3D0x555556012ff0, vpos=3D3, updating_menu_p=3Dfalse) at dispnew.c:5326 126 if (tty->termscript) (gdb) p curY (tty) $1 =3D 3 (gdb) p FrameRows (tty) - 1 $2 =3D 3 (gdb) This one still happens (this is after C-x 2): #5 0x000055555558b697 in build_frame_matrix_from_leaf_window (frame_matrix=3D0x555556050420, w=3D0x555556013210) at dispnew.c:2647 > > And it moves the assignment of FrameRows to handle_window_change_signal > in dispnew.c. Doing it in adjust_frame_size was silly (as Gerd M=C3=B6ll= mann > noticed earlier). FrameRows should be the height of the tty which can > be smaller than the height of our frame. Emacs is supposed to store it > but not to modify it according to our capabilities. > I don't have the expert opinion of how it should be. But I agree that a source of the problem is that the tty can be smaller than the frame. Frame and terminal may have different sizes and this creates inconsistencies. 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 >=3D FRAME_TOTAL_LINES (f)) return; But this is checking the *frame*. Later, the assertion in cmcheckmagic will be made about the *terminal*. I think the frame never gets smaller than 2 lines (there's code in handle_window_change_signal to prevent it), but the tty can. So if we're in a 1-line terminal, and updating the 2nd line, the above code sees nothing wrong (the frame still has 2 lines) but cmcheckmagick won't like it (the terminal doesn't have a 2nd line). (Usual disclaimer: I don't know very well how this works. I'm often brainstorming). > And it moves the assignment of FrameRows to handle_window_change_signal > in dispnew.c. In practice, that code (in the new place you put it) is still inside an if:= the if (width > 5 && height > 2) in handle_window_change_signal. This means that in e.g. a 1-line terminal, you won't be setting FrameRows to the actual number of lines of terminal (1), as you wanted. It will still be the old value, e.g. 2, and it may make cmcheckmagic crash by trying to do things in line 2 (which exists in the frame, which has 2 lines) but not in the terminal (which doesn't have a 2nd line). One option seems to have FrameRows always match the amount of terminal lines. Can we remove the "if (=E2=80=A6 height >2)" limitation, and allow 1-line, 2-line frames etc.? (To really match the terminal size). Other changes may be needed in other places, to avoid working with very small frames.. Otherwise, if we let FrameRows be larger than the amount of terminal lines, another option could be: At the beginning of tty_write_glyphs, check whether we've been asked to write glyphs in a line which is higher than the amount of lines in the terminal. If so, return without writing anything. (Because the line would be invisible). Or maybe in some of the callers of tty_write_glyphs. Don't call tty_write_glyphs to write glyphs in a line which is not visible (it exists in the frame, but doesn't exist in the terminal). By the way, I saw that the cmcheckmagic code checks curY (tty) >=3D FrameRows (tty) - 1, note the -1, whereas the dispnew.c code I quote above doesn't use the -1. I hope this is ok. As mentioned they're checking different things so it may be ok, though I don't understand why the -1.