From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#39977: 28.0.50; Unhelpful stack trace Date: Sun, 22 Mar 2020 19:20:33 +0100 Message-ID: <88e06868-cfc2-7109-b5ea-71fea3aa897e@gmx.at> References: <83imj88tpt.fsf@gnu.org> <550fbc22-09db-d30b-c194-8f26b5dca05f@gmx.at> <83wo7o6nxs.fsf@gnu.org> <60dd4ced-a2e5-ed17-0570-b7bdd2a557af@gmx.at> <83blozckn2.fsf@gnu.org> <01305dbc-c69b-baf9-f0bf-1e5b8c04d970@gmx.at> <83y2s2bswl.fsf@gnu.org> <3ac189d0-5d05-fdf9-0922-0c464b1b17c3@gmx.at> <83k13lbgux.fsf@gnu.org> <83d09cb9gz.fsf@gnu.org> <69a74f9e-079b-a771-0213-f60ed0bf5720@gmx.at> <83y2rzf08m.fsf@gnu.org> <7a0b9999-6778-6235-fbc9-2a24b4e3bc53@gmx.at> <83tv2mg9j0.fsf@gnu.org> <9684641c-a59a-4ed6-a6b4-d3238f789050@gmx.at> <83sgi6g461.fsf@gnu.org> <90ac4084-4fbb-b5d7-6a7c-597d8f08e88a@gmx.at> <83imj1g1eu.fsf@gnu.org> <835zf1fobf.fsf@gnu.org> <4472dbf8-eec0-72eb-a4ad-c6b382d27f1f@gmx.at> <83zhcce7n2.fsf@gnu.org> <9a3df43d-4a83-bed0-9ad1-b59cf11b4c9c@gmx.at> <838sjtetmp.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="------------CA36CE8C6D6763F6338D104A" Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="56064"; mail-complaints-to="usenet@ciao.gmane.io" Cc: enometh@meer.net, 39977@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Mar 22 19:21:37 2020 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 1jG5E8-000ETY-FC for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 22 Mar 2020 19:21:36 +0100 Original-Received: from localhost ([::1]:48794 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jG5E7-0008UU-BX for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 22 Mar 2020 14:21:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56605) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jG5Db-0008UM-CR for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2020 14:21:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jG5Da-0001O3-1U for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2020 14:21:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:44921) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jG5DZ-0001Nx-UI for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2020 14:21:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jG5DZ-0000zI-R4 for bug-gnu-emacs@gnu.org; Sun, 22 Mar 2020 14:21:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 22 Mar 2020 18:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 39977 X-GNU-PR-Package: emacs Original-Received: via spool by 39977-submit@debbugs.gnu.org id=B39977.15849012483753 (code B ref 39977); Sun, 22 Mar 2020 18:21:01 +0000 Original-Received: (at 39977) by debbugs.gnu.org; 22 Mar 2020 18:20:48 +0000 Original-Received: from localhost ([127.0.0.1]:50894 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jG5DL-0000yQ-AN for submit@debbugs.gnu.org; Sun, 22 Mar 2020 14:20:47 -0400 Original-Received: from mout.gmx.net ([212.227.15.15]:39705) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jG5DJ-0000y8-8u for 39977@debbugs.gnu.org; Sun, 22 Mar 2020 14:20:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1584901235; bh=0QgLIffPSaf9JBIxoYDsg6sPmLkGq0OsfFJNuMbNt4k=; h=X-UI-Sender-Class:Subject:To:Cc:References:From:Date:In-Reply-To; b=IrLsiXY+Fuz0hTF+MXQxidsBNqfDpqYd38FTbYCGWe82JtZ8tE0lQUONaestfLyKX yZCJGQZXAFnw9GEEItaQX1rnormqw29fxbpxGeztEehyB8xwyaPwD+TB+jbEjby7Y+ HuAe5l8w9g635UMwjDqlFVBJCM8ZCfx9gvodwx8I= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Original-Received: from [192.168.1.101] ([212.95.5.244]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1ML9yS-1iy0MT02Pi-00IFxl; Sun, 22 Mar 2020 19:20:35 +0100 In-Reply-To: <838sjtetmp.fsf@gnu.org> Content-Language: en-US X-Provags-ID: V03:K1:RN0Z6vdp3BiTIfwIj1iuYimrfv0YR00UxShzBb3leJGjuhg/FJF GlTNYqLNYG3qlXprZmgrWSZLk2i9mR3qWt/Af5LtGPrOiDnMH1Sxzlqpi4+gSJTIARO5Ssd /9K0/v474hqQ8b2JMlWKRdcE9aCyZqJyGRERaLb3xdyLFHAUG08XciaM7N8dNyAdeXEcSQu ijczvh9hP1yFb2ow6JC6A== X-UI-Out-Filterresults: notjunk:1;V03:K0:jICGt61p5Pg=:qKl4/KZ7hhh5M2PL7YHX/8 TUP0kpDy4N+6cWOQ9rwXG+JlGIUshDY4xPGAr3ThTso55mtB6wB00x82yEW3pHUIoZebtvNXW ehP0rkqM9oZ6DdVPnYy0FzNNmobUlKZHP3AwJoSxGVF8zohNICQ82yXBi+Ag/jSmaMmXmP+tp GUbqTWRIa6y/pU5MqVvO+aShsqhjTJrbuEOa4Ef17dVbO6SRsw6DQp3Sl6HDLxNvZJQ/PBKq4 Vjnq4G9mlF+7+m8FJ0RlU5fq/OQ68gc97HBamsgnW7d/xs2S07Imblqqjsl5eZPxGbFQZu/Tr Plt3VXB3KZb22FMyYj+UNUh1kuLTdMVkvVjGqtgrqDMAdY0CHT98P+Syq9GN+DcPKP7PIHrAM wHzX1XJEWdyqdb4gb0LTfBXgl4yNcyiVHE6/GmkL8CXiAh1yan85GUz6Z1NJjQydENTQfbdRT nAQZR7YxcentWJEESRgpdP4QabaBz3UPGdKWgcooVFqCyMTgbVpfVHWavR8Xd2BFmclscIYe+ HM5+Y3SUZr8cMY57+nnZDZZcHGuSXFmvcaP5B94Ttavh7rbEb+dOcKM0KixVOE0IXyOaF6Tvp SygjcgA7Oa2GdpR58huQzeLrYiu78heTEzTBwUge7XgfCqCZnb/og5czKREkozK16pc1F10G+ MaD0u0ts9fIZL2+LqR9i++77wkxhYDeO8xYexHUQwofJmNoRkDwUryR6Xrmdsf8atgWPYz4we Wfz2eSaSAe8S+G8MW08Z63bcdlPkIRHM1XSUBV1Fw59sIFSYanuuNv7hi+tS5fhi8twfcC4j X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 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" Xref: news.gmane.io gmane.emacs.bugs:177628 Archived-At: This is a multi-part message in MIME format. --------------CA36CE8C6D6763F6338D104A Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit >> Not really. It's easy for delete_frame to refuse deleting a frame right >> at the beginning. But once it has accepted a deletion, it might become >> hard to deal with all the consequences. > > I don't think I understand where you are going with this. Once an initial frame has been created, Lisp code should be always able to rely on the truth of (and (frame-live-p (selected-frame)) (window-live-p (selected-window)) (eq (frame-selected-window (selected-frame)) (selected-window))) Whenever this basic invariant is violated, there is no guarantee that frame and window management will produce correct results. Currently, this invariance is no longer guaranteed if Lisp code is allowed to manipulate frames and windows arbitrarily while processing the mode line or the frame title. IMO there are three possible ways to deal with this problem: (1) Let the redisplay code handle it. (2) Let the frame and window management handle it by disallowing such operations while they are issued by the mode line or frame title processing code. (3) Ignore it and let the frame/window management routines catch up with it later. Using (1) way my initial idea. The patch I proposed handles simple cases like Madhu's bug. It will certainly not handle more sophisticated cases where, for example, an application kills two frames in a row. (2) is by far the most simple and reliable approach but it will restrict applications in what they are allowed to do when processing a mode line or frame title. (3) means that frame/window management proceeds in a non-deterministic fashion as long as it has not detected that its basic invariant has been violated. > This isn't about trust. This is about letting users' Lisp do anything > they want as long as the results allow redisplay to continue after > that Lisp returns. I don't think it's right to disallow certain > actions just because they _might_ cause problems. You again care about redisplay only. Which means that frame/window management is second-class as far as safety is concerned. >> > No, they are there in cases where we simply don't know how to >> > continue. >> >> If that's the reason, then SELECTED_FRAME can easily set selected_frame >> to some live frame and continue. > > Something like that, yes. I attach a patch that does that. If you try it with a recipe like loading (defvar foo '(:eval (when (> (length (frame-list)) 1) (delete-frame (next-frame))))) (setq-default mode-line-format foo) (make-frame) with emacs -Q you will see that while it works around the crash it still produces a Wrong type argument: window-live-p, # error in redisplay. martin --------------CA36CE8C6D6763F6338D104A Content-Type: text/x-patch; name="SELECTD_FRAME.diff" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="SELECTD_FRAME.diff" --- a/src/frame.c +++ b/src/frame.c @@ -1843,6 +1843,36 @@ other_frames (struct frame *f, bool invisible, boo= l force) return false; } =20 + +/** Select some live frame. */ +bool +select_some_frame (void) +{ + Lisp_Object tail; + Lisp_Object frame UNINIT; + + FOR_EACH_FRAME (tail, frame) + { + struct frame *f =3D XFRAME (frame); + + if (!FRAME_PARENT_FRAME (f) && !FRAME_TOOLTIP_P (f)) + { + /* Select FRAME without switching to it. This sets up the + selected frame and the selected window and avoids aborting + as when redisplay selects a dead frame (Bug#39977). */ + selected_frame =3D frame; + if (!WINDOW_LIVE_P (FRAME_SELECTED_WINDOW (f))) + FRAME_SELECTED_WINDOW (f) =3D Fframe_first_window (frame); + selected_window =3D FRAME_SELECTED_WINDOW (f); + + return true; + } + } + + return false; +} + + /* Make sure that minibuf_window doesn't refer to FRAME's minibuffer window. Preferably use the selected frame's minibuffer window instead. If the selected frame doesn't have one, get some other diff --git a/src/frame.h b/src/frame.h index a54b8623e5..807938fd9f 100644 --- a/src/frame.h +++ b/src/frame.h @@ -1363,14 +1363,17 @@ window_system_available (struct frame *f) =20 extern Lisp_Object Vframe_list; =20 +bool select_some_frame (void); + /* Value is a pointer to the selected frame. If the selected frame isn't live, abort. */ =20 #define SELECTED_FRAME() \ - ((FRAMEP (selected_frame) \ - && FRAME_LIVE_P (XFRAME (selected_frame))) \ - ? XFRAME (selected_frame) \ - : (emacs_abort (), (struct frame *) 0)) + (((FRAMEP (selected_frame) \ + && FRAME_LIVE_P (XFRAME (selected_frame))) \ + || select_some_frame ()) \ + ? XFRAME (selected_frame) \ + : (emacs_abort (), (struct frame *) 0)) =20 =0C /***********************************************************************= --------------CA36CE8C6D6763F6338D104A--