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: Thu, 05 Sep 2024 18:10:20 +0300 Message-ID: <86seue2l2b.fsf@gnu.org> References: <86le07624j.fsf@gnu.org> <60579ab6-db81-4f6e-b281-0cee03dc3b82@gmx.at> <86cyli4fxj.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39592"; 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 Thu Sep 05 17:55:40 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 1smEpe-000AB9-Jl for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Sep 2024 17:55:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1smEp1-0001vs-JV; Thu, 05 Sep 2024 11:54:59 -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 1smEoz-0001nA-FS for bug-gnu-emacs@gnu.org; Thu, 05 Sep 2024 11:54:57 -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 1smEoz-0002ka-6F for bug-gnu-emacs@gnu.org; Thu, 05 Sep 2024 11:54:57 -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=m6hk0XsXCEn3h313oY9TK0HV9QtSOseY/mNKP0+0FKQ=; b=flmgrLhNSRLaLLXsE7uusTK+3RoWpYtCy8pBVuZ21rfBFBMUvNIH5ItKcVrQgFDCwGJ+5zhFpZguKHnZYsvnQo2XUH2IQPrTcmhFiljMFqQp9dQXwVdlhg1P6jRXO9HK/3vZ9GbN0SnObWyrb6Tx65KbIK8W+zG/dmtqtzGkpqrvmOey6WFU9AEr+aa3EF0hfBGzWGXCXIGQm8U4+4Auuim0vkr1ZBxmjry4g7twmdiw5aLp+YOGuLy4iyzkcUzIvArncBwpFq6lJRC6xWikcgB5mjnV2VUlBNLYWNHQxfDdR/3K9URajqtA+MgNi9Nbo4HMMTeTG4BB8P1kFfuPjg==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1smEq1-0003wp-Vq for bug-gnu-emacs@gnu.org; Thu, 05 Sep 2024 11:56:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Sep 2024 15:56: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.172555171015034 (code B ref 73022); Thu, 05 Sep 2024 15:56:01 +0000 Original-Received: (at 73022) by debbugs.gnu.org; 5 Sep 2024 15:55:10 +0000 Original-Received: from localhost ([127.0.0.1]:37914 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1smEpC-0003uP-3x for submit@debbugs.gnu.org; Thu, 05 Sep 2024 11:55:10 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56300) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1smEXu-0002f6-1o for 73022@debbugs.gnu.org; Thu, 05 Sep 2024 11:37:18 -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 1smE7t-0001e5-9O; Thu, 05 Sep 2024 11:10:25 -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=m6hk0XsXCEn3h313oY9TK0HV9QtSOseY/mNKP0+0FKQ=; b=Y7pgVzebbUL0 5JJXx6LJqlC76B+6daX5Me2SaLlOEd9zeungUBDSsrhpUIZDN37d5XASN36x6Qt9TTXc9X9Dk6uEY cPlIBpZoJ6cSA7b6onwo30KZ0Q0hCEWoo8z/PYXPmWsOzVlxO1Vv2gnTIMn9JAzV7Z5vVaM8uVpkU jBL1d/xnjntwk7p6ww4bDLFOnD5aDmTQPFuybFfsQ6+QtBOOAW76beC2HI9AftC9zITXtX/z0r8ko CMUodkH8dTTbEl35dnwrG0GVWy1cQBirwDeEdaAK8nINAI7STUNUeD/ozKISMWAWlKZK/tAQH5QWm 1SeIijGFW2BFkzsO5BLhxA==; In-Reply-To: (message from martin rudalics on Thu, 5 Sep 2024 16:45:52 +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:291266 Archived-At: > Date: Thu, 5 Sep 2024 16:45:52 +0200 > Cc: n142857@gmail.com, 73022@debbugs.gnu.org > From: martin rudalics > > >> If so, then this violation might be caused by the fact that we > >> (1) did resize windows according to the new sizes but (2) did not update > >> the frame sizes accordingly. > > > > Can you elaborate on how this could be possible? I always thought we > > first allocate the frame matrices, and then the window matrices (by > > suballocating them from the frame matrices). Am I mistaken? > > But if glyph_row_slice_p (window_row, frame_row) fails, something else > must have invalidated that. I made that change here more than three > years ago and I can neither remember whether an assertion violation made > me do it or a crash nor why I did chose a term like "congruent" in the > comment. I agree with the theory that the frame matrices were reallocated whereas the window matrices weren't, or the other way around. I just don't understand how it could have happened, given the code we have. I noticed that causing this assertion to fail is not very easy. For example, if I drag the terminal emulator window one line at a time, I can never cause it, even if I get to frame sizes that are much smaller than the minimum we need for 2 windows. Somehow, I need to drag the frame so it resizes by several lines and/or columns. Not sure why. > One possibility I cannot exclude is that adjust_frame_size tries to > resize windows, that step (silently) fails in window_resize_check, the > old values stay in place but the new frame sizes are applied by > adjust_frame_size. But precisely this scenario cannot be healed by my > patch so it's unlikely that it was the cause for the problem I > experienced back then. What is supposed to happen, with the current code, when the frame is resized to less than the minimum dimensions we allow? Shouldn't we disallow/refuse such resizes? And if we don't refuse, what will happen to the windows? E.g., if the frame is not tall enough to show the menu bar, the two mode lines, the mini-window, and at least one line for each of the two windows, what should I expect to see on display? > > Moving code in adjust_frame_glyphs could affect the assertion if the > > assertion was being hit while adjust_frame_glyphs is still being > > executed. But that is not the case, so I don't understand how moving > > some code in adjust_frame_glyphs without changing it could affect the > > assertion violation. I'm probably missing something. > > I'm still too dense to understand what "Moving code" and "moving some > code" could mean in this context. If you have enough patience left, > please elaborate. Taking some code and moving it to another place in the same function can only affect what's going on in that function and the functions it calls. For example, if you had foo (); bar (); baz (); and then you move the call to baz to be before the call to bar, like this: foo (); baz (); bar (); then I can understand why bar and its subroutines are affected. But once we are done with this code, all the 3 calls have been made, and the order in which they were made can hardly matter for the code which runs after that, right? So if the crash was inside the call to bar, then I could understand how moving the call to baz before it could affect the crash. But the backtrace from the assertion violation didn't show adjust_frame_glyphs anywhere on the call-stack, so I don't understand how simply rearranging code inside adjust_frame_glyphs could change something _outside_ it.