From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Po Lu via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#61667: 29.0.60; Failure to redisplay Date: Wed, 22 Feb 2023 10:41:20 +0800 Message-ID: <877cwactgv.fsf@yahoo.com> References: <04d7cb31-684c-07c0-ee7b-503514fc1a85@yandex.ru> <87a617eanz.fsf@yahoo.com> <4306cb76-a44c-3101-e43c-fd64afae4a51@yandex.ru> <871qmje2ws.fsf@yahoo.com> <83edqjtbss.fsf@gnu.org> <4e5e2a46-9b07-206a-6774-9f98f34cbd14@yandex.ru> <83y1orrolh.fsf@gnu.org> <83sfeyswdw.fsf@gnu.org> Reply-To: Po Lu Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18723"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 61667@debbugs.gnu.org, Dmitry Gutov To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Feb 22 03:44:30 2023 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 1pUf7O-0004hj-5Y for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 22 Feb 2023 03:44:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pUf6y-0003I5-Jl; Tue, 21 Feb 2023 21:44:04 -0500 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 1pUf6x-0003Hn-Am for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2023 21:44:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pUf6w-0005gw-R9 for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2023 21:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pUf6w-0005wL-6r for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2023 21:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Po Lu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Feb 2023 02:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61667 X-GNU-PR-Package: emacs Original-Received: via spool by 61667-submit@debbugs.gnu.org id=B61667.167703381722795 (code B ref 61667); Wed, 22 Feb 2023 02:44:02 +0000 Original-Received: (at 61667) by debbugs.gnu.org; 22 Feb 2023 02:43:37 +0000 Original-Received: from localhost ([127.0.0.1]:57624 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUf6X-0005va-2D for submit@debbugs.gnu.org; Tue, 21 Feb 2023 21:43:37 -0500 Original-Received: from sonic316-48.consmr.mail.ne1.yahoo.com ([66.163.187.174]:34925) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUf6U-0005vM-E3 for 61667@debbugs.gnu.org; Tue, 21 Feb 2023 21:43:36 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677033809; bh=h+H1CKZwW1eAQlazjngpN3oYb14YeZZXH533/laJQ2U=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From:Subject:Reply-To; b=mrQsUY8NroXjmHdaqrYCXZaYeTF591tNdUYHplGwpqScaYRzVFxxTG2MnRS1RtayTleTKAoSGcEqlgexAZzOli2rTvPPTWpAVOlu7tyu2v/WRIzWbEEW8Z02xoYj7HOaY9J28t1bHeBH5F10BIdg16ycgmmrFi23OKcjLbi8pc+efhj7XgyBcf8O4AZNy02k77Igof+gdjKAKc0R8iu0SHvEkmvANhgfPs2WHw5N5h+H2og+f+eipaEY2SFr23OWYBp0kC7CixYpotfKKKoWNSAjt/lnxHUoA6PgbWPupPO2h8dPp1913K5166v/PhVCQAQdRdAKepbvA7OCr9uuhw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1677033809; bh=EPe1rU/1EdKXfbwss/vo8rNkXSia1aMV59dTO/6aDrD=; h=X-Sonic-MF:From:To:Subject:Date:From:Subject; b=qNvj1NuxcWuRvVvDjNLcy2MAhAHjI/CtuAKIwpcG+uyenQ8jwnmqNTXUeVmaP8Vbr/agaQmNTe7Zrme0Nf0c7beajCfVRMAAvlq4Gi3LKZpnlVHePUEdbqHq0Qt7qkSOR7aqspAN7QUSY1GstWIcYiQChaQobL4gM+VJlNMh7u7h7uJww3Q3yN9C8qNcvVbGpnKGVM5FeI6FO3X6XXqTJ8L7tYP3sApwMqqJQZ/dE4xr4zlBN2UsMyYcyoiXZS8AIabBmaaxH9WnUg/HHL6NOZpM99oSuW0BxUn39S2HC/lu35LvgKgfM9ZqigijtLONoHMN5d/qG7BKbOeFnYV7/g== X-YMail-OSG: _b8UCmEVM1nkRSrmBVGliygeumTSX1H.E8TqHNBrnKhMvbwhcSJx1K2DoYdBvBT 0P4MGyHxqSkSpPEGZ8ACuKLkuhWQV2DMHbZiDew07u.8WbxYJDiWn4jqaY62Y_rUgu_Dwxh7a6Tx fxdMp1mjC9Vm5vFLQzccgLtdUT0iYib5ml3SAe2fpkcRyL3SJWj51D8YkEF5ZMGekHkuJi5RxUJM fCpdnKtWXcDEsOsE.xvVHgon2Jt1piDQiNkImFU0S_vBDvCTX851rUod18dZZ33YjFW3nJRAP_ox xc8nG5uzHM99RPNGU24PBc2IXHni9vUaG0xhcUuyMoydTWxODTYyHY3SOXBienifUYER09UUMl18 v9L7N8ijh9zjbFzRC8zBZPAouufgwbfDQrXo.SMhNt6dpaypTPFzRXxk62rINGinV.FghGMLRjH_ aJeLJbTnSnFpNH1MyKqvNx7S_K46TXTJZkE_P3VZFYTGhpTC2ThVzrRXqDTthMwqKycuL8chveYT WLzQV5Tb3sgv71.O0g0Rl9WtCvwKxCKCYqnuXJgzGdZt32vUAcPkHUpMsCbD5nlqkbIWf22rZtgy 8baFtFI44VIMJ2QNA_w919WCIdB0F12zqCUmi62e9hHI.99BXDeuEZIYgWWqW1oeWPQmHkXByBwy NVYyCgDW2N1yzeHVKBO7ehClcFYsLflRzalL5DYgOlENj2WFPjLFko7IaOxhK1WjvOzu8hVe0XjY TRIYDwmdllPTuhDspiuPCBlU21zfncKsVJZZ1s5KhEdL4kLxWAC75cuGuJFnqx.H_Z7JO1zTFaLu FgS1HnRc_ygmsgobSXnPHOWgCpbq2Ii.paLrGehwO2 X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Wed, 22 Feb 2023 02:43:29 +0000 Original-Received: by hermes--production-sg3-9fc5746c8-97g7j (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID 1f1111ee78b7394992ed6a57d59847da; Wed, 22 Feb 2023 02:41:25 +0000 (UTC) In-Reply-To: <83sfeyswdw.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 21 Feb 2023 20:31:39 +0200") X-Mailer: WebService/1.1.21183 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.yahoo 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:256316 Archived-At: Eli Zaretskii writes: >> Date: Tue, 21 Feb 2023 19:25:28 +0200 >> Cc: luangruo@yahoo.com, 61667@debbugs.gnu.org >> From: Dmitry Gutov >> >> > I'm not surer I follow: why should a frame resize in this case? You >> > just visit a file in an existing window of an existing frame, right? >> > Or is the situation more complicated? If the latter, please tell the >> > details, they could be relevant. >> >> Given how slow the unoptimized build is, I can usually start (and >> finish) typing the command before Emacs has fully finished processing >> the init script, including the default face customizations (which result >> in frame resizing). >> >> >> So if I wait for it, and then use 'C-x b' (with Ido's support for >> >> recentf), then I also can trigger the problem. >> > >> > Not following again: wait for what? And what happens when you use >> > "C-x b"? >> >> 'C-x b' followed by the file name from history, followed by RET -> >> visiting the previously visited file. From recentf. >> >> This behavior is driven by the option ido-virtual-buffers. Unlikely >> affects something. >> >> But it allows me to shorten the scenario of visiting a file for the >> first time after launching Emacs, so that I can trigger the bug faster >> (over several tries). > > So you: > > . start Emacs > . wait for the initial frame to be redrawn after the init files are > processed > . visit a file by typing "C-x b" and selecting a file from a list > > And then you see an empty window with the frame's title showing the > file you selected. Is that correct? If so, what do you see on the > mode line as the buffer name? > >> Overall, though, the unoptimized build makes it harder to reproduce: >> I've only managed that 3 times, so far. > > Which likely means this is some kind of timing issue. Which perhaps > also explains why trace-redisplay stops it from happening: it slows > down redisplay because it needs to output the traces. So we are > looking at some X or GTK event that comes in and somehow interrupts or > prevents redisplay from doing its job, after it evidently started > (because the frame title is updated at the beginning of a redisplay > cycle)? Or maybe it's something that prevents us from swapping the > double-buffering buffers so that the redrawn stuff is actually shown > on the glass? > >> But the echo area is not getting redrawn either: the selection of >> buffers to switch to is still visible as it was when I pressed RET. Just >> the title bar changes. The echo area is updated together with the main >> window showing the buffer. > > The echo area is shown in a window, so that seems to be part of not > updating the windows on display. Thanks. Would you please start by instrumenting xterm.c as follows? diff --git a/src/xterm.c b/src/xterm.c index 5feaa4aef0f..999ae5d37fb 100644 --- a/src/xterm.c +++ b/src/xterm.c @@ -7518,6 +7518,10 @@ XTframe_up_to_date (struct frame *f) FRAME_MOUSE_UPDATE (f); #ifdef HAVE_XDBE + fprintf (stderr, "XTframe_up_to_date: %d, %d\n", + buffer_flipping_blocked_p (), + FRAME_X_NEED_BUFFER_FLIP (f)); + if (!buffer_flipping_blocked_p () && FRAME_X_NEED_BUFFER_FLIP (f)) show_back_buffer (f); @@ -17736,6 +17740,8 @@ x_flush_dirty_back_buffer_on (struct frame *f) || !FRAME_X_NEED_BUFFER_FLIP (f)) return; + fprintf (stderr, "x_flush_dirty_back_buffer_on: called\n"); + show_back_buffer (f); #endif } Then, please tell if anything at all is printed when the buffer flipping fails to happen. In addition, does this happen on a build without Cairo? One theory is that an event somehow arrives during redisplay and causes `x_flush_dirty_back_buffer_on' to be called, and the Cairo code is missing a call to `x_mark_frame_dirty' somewhere, which causes the next buffer flip to not take effect.