From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: martin rudalics via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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, 5 Sep 2024 18:27:07 +0200 Message-ID: <24026689-43a7-4340-ba0e-54d8e8c655ed@gmx.at> References: <86le07624j.fsf@gnu.org> <60579ab6-db81-4f6e-b281-0cee03dc3b82@gmx.at> <86cyli4fxj.fsf@gnu.org> <86seue2l2b.fsf@gnu.org> Reply-To: martin rudalics Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17522"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: n142857@gmail.com, 73022@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 05 18:28:04 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 1smFL2-0004OG-1u for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Sep 2024 18:28:04 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1smFKw-0005gC-Hk; Thu, 05 Sep 2024 12:27:58 -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 1smFKv-0005fz-9H for bug-gnu-emacs@gnu.org; Thu, 05 Sep 2024 12:27: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 1smFKv-0008Sn-0O for bug-gnu-emacs@gnu.org; Thu, 05 Sep 2024 12:27:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=Ppu/atj9dBpMSK9voBWz1DcEMzF4/Xd1DZ+JOO/RdUc=; b=WQsE4viDQJJgpE6rAYUQPybdTUGAIsCB5HnJOBMQM4Jl0qSrw25a8TGPV2w2tOMCmorNMhClgEbGaeyiltc5llgqGQldwM0Q6vZ1ctMl9Ty+VSg3+tk3xuZ9s0bDWqhglLxV+bG8Y6jd+s1N3mHC/ItZHisBDW3bu+sKoMWIfcVqquInrTSFP7hSp4UGB5KRwTZo9lBNJfJDYiSZqAlPiMe/Tnhjmgst19ph8vDp2zN/x17IeKMH8F165Z3ScVT2DBkQWlYVVodB0gm7M7yMrlrOaKIL4P3Tz5iKI4AEE3u5wUFrCjLjRkX2C4VFvAjzP+8ljld8hSKVcqFnucnhFA==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1smFLy-0006bB-64 for bug-gnu-emacs@gnu.org; Thu, 05 Sep 2024 12:29:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Sep 2024 16:29:02 +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.172555370825244 (code B ref 73022); Thu, 05 Sep 2024 16:29:02 +0000 Original-Received: (at 73022) by debbugs.gnu.org; 5 Sep 2024 16:28:28 +0000 Original-Received: from localhost ([127.0.0.1]:38002 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1smFLQ-0006Z5-Df for submit@debbugs.gnu.org; Thu, 05 Sep 2024 12:28:28 -0400 Original-Received: from mout.gmx.net ([212.227.17.20]:56965) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1smFLO-0006YT-6n for 73022@debbugs.gnu.org; Thu, 05 Sep 2024 12:28:27 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmx.at; s=s31663417; t=1725553633; x=1726158433; i=rudalics@gmx.at; bh=Ppu/atj9dBpMSK9voBWz1DcEMzF4/Xd1DZ+JOO/RdUc=; h=X-UI-Sender-Class:Message-ID:Date:MIME-Version:Subject:To:Cc: References:From:In-Reply-To:Content-Type: Content-Transfer-Encoding:cc:content-transfer-encoding: content-type:date:from:message-id:mime-version:reply-to:subject: to; b=FVYFW+8f0PU5sRtQvSOZDKydAIcIdDNZEq3RCvOaixjDpx+26mfaz0pUT68rkb9I FUolidWi6ZJHxlQDPPqyzSP8ulleFs5wyg9FyTER9jTzcaBIFn/ITqJGXvAklRFcQ ykCa9iviBJJXzcyqKDDqNFpZpMj4FIQbzSSlgm6pG1PrSxwTB0/Tbzojiw4vb87eG bvGBzgSVnXEzLCFk5W92rj6osR+AvRzsC1DhRsKWM0A9tAmE0jbellvRpS5l4ENaT fTtUfI4TELQN6d1VvyCZG75gT1G128FZEit14Ac6KKt/6eN7mr/+rUp7xQZQX/67b ZTFNIvfKmycHD82j1A== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Original-Received: from [192.168.31.113] ([212.95.5.159]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N8ofO-1s1JN12zGo-00yJGy; Thu, 05 Sep 2024 18:27:13 +0200 Content-Language: en-US In-Reply-To: <86seue2l2b.fsf@gnu.org> X-Provags-ID: V03:K1:SIZkMwDoQSds5HD8saM+uBdXfKdnOGco07Vve8Qy7G/D/SH2hDh SIAXnAGoXGdr1KD5fyVdE9C1VDSjkp1pDpqOFrw2j5i+gkYAwfXM/E4y7SECYK7ozB2F37d GZhCl7GkMZMfkNJ1beSEy4RDin9KuSem3KTd5GsJBijfDnXhds4PoTdei5umWe8+TkdR32z TSyo9ujDtPbTOcLPt1GJg== UI-OutboundReport: notjunk:1;M01:P0:A33tYocSjZk=;Wi0LdGyE8GY7SHM2wV6PCB/rYJ4 KtZqiznfn0Zv6x3YVHVKs+1SStJBmZolVA1YcyUxBap+YdFInnMi+Tq45oX2SX6bZFLuioueK +5TLPiQ7Si5qFPchveYIpD0AoEL1ATmhAoMRrlClpI+foUsETSiO/aMFcxBS9kG1cfe+Oqe/I tOa80mourkaRmHksTBPKlWUUfACcTtiqe9tWYemTx9cD68siSMBWV+EAR48Fq8lMKDMv8tdcV qT29TBhTk53duA/uwzK2Ows9G1s6mV1MYc9jwqzBmotlgR+c9uO4lorehVqqdrvTOApqgXVhK fgi8+tvV4z4lprJUAP7gJVaK8y9apjDDWVKhkhoMxhZcJ+8tnHwAdjQ97UH+HetF1w/VPsM1U Bw/e7SQ7ATsc9IPXQtgxerGQdjk4XTE1y1aID4CbAmkkAiEXzHk2Rtz/9V0g/WhYV5cDRddMt ZqEK49CN3yTjYSKY63AKo42/8wCfarjepuSXR/o/8ZIPqv5DZ126eCS1HiS9iDAA7/ZI8cjtD jSTtI4PyAuPaEfk7BdzkJ4fAO9Ga+1QtX4JcfG7zU1TUr87gEwoNIKdW5WZM/DXg9m4jigt6z Eoxi71JZmkN4AG6/4SyY45SRHutN/Bt+OG7Ov4zHUXhViQ8fbsHQezZYb6T9hiN0mlcVGe7ne BRgywmTufALg3i/SOiW+MlD67Jv1xUOMI3MgAP7VvzH1KTvRNhQSVd1Cts4tEd1gCsezJE9n9 KtiP/a2Whvjy1Jsw9RUPIeBrMtSen82966dB07tv+7d4iLoKOjuVAtY54uxfvxBeDP4uWixR 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:291271 Archived-At: > 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? As for GUI frames I wrote some code to handle that but you didn't like it back then. Basically, we should do the following: - Add min-size-hints so the window manage never tries to make the frame to small. These have to correspond to the current window layout and the window decorations - a frame with split windows has a larger minimum size than one with one window only as we can see in the present thread. - When the window manager doesn't comply, simple ignore the shrink request. Portions of our frame that don't fit will be clipped by the window manager. I wrote some code to always keep the minibuffer window visible in such case but cannot remember whether it works well. My WM (and Windows too) never tried to make a GUI frame smaller than I wanted. On terminal emulators we should (or even do) conceptually the same as with a non-compliant WM. The terminal emulator has to do the clipping just like the WM. > 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 I moved the assignments within adjust_frame_size (baz) in front of the resize_frame_windows (bar) calls. Is it that what you mean? > 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. Do you mean adjust_frame_size instead of adjust_frame_glyphs here so the fact that makes you wonder is that adjust_frame_size never shows up in the backtraces? I could imagine that resize_frame_windows (or even 'window--pixel-to-total') mess up things in a way that confuses frame based redisplay later. In adjust_frame_glyphs_for_frame_redisplay we do eassert (matrix_dim.width == FRAME_TOTAL_COLS (f) && matrix_dim.height == FRAME_TOTAL_LINES (f)); and I wonder whether there's an execution path that could bypass that assertion. martin