From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id A17253858420; Sat, 8 Feb 2025 20:11:44 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A17253858420 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1739045504; bh=IYaLwOkbZRmnHJ0pHQYcwH7+yrzlwFTvxByI4POEUAg=; h=From:To:Subject:Date:In-Reply-To:References:From; b=y1WYIKmBES3AOfyMw9+Ma3WhIlsnU4QJRPfiX/v5V4si6sGIl0PBxs7TechEg3Jj4 dQHQ7fB0N6Y1d5EeJJLFcZ6zUl6tKZBN1X8AxOg0dQFoc3Z2HWtc8Y1EjufQp0yJQF iDvTHrilnf+BxbmoFK+VnHsdXGN8c25Uq9qJ3yl0= From: "cvs-commit at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug tui/32623] TUI console window doesn't update while inferior is running Date: Sat, 08 Feb 2025 20:11:43 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: tui X-Bugzilla-Version: 16.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: cvs-commit at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: 16.3 X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D32623 --- Comment #3 from Sourceware Commits --- The gdb-16-branch branch has been updated by Andrew Burgess : https://sourceware.org/git/gitweb.cgi?p=3Dbinutils-gdb.git;h=3D2b646bb87677= b206af8f88f132a12a4181b6e356 commit 2b646bb87677b206af8f88f132a12a4181b6e356 Author: Andrew Burgess Date: Wed Feb 5 20:12:03 2025 +0000 gdb/tui: use wrefresh if output is not surpressed Recent work in the TUI has improved GDB's use of the curses wnoutrefresh and doupdate mechanism, which improves performance by batching together updates and then doing a single set of writes to the screen when doupdate is finally called. The tui_batch_rendering type is a RAII class which, in its destructor, calls doupdate to send the batched updates to the screen. However, if there is no tui_batch_rendering active on the call stack then any wnoutrefresh calls will remain batched but undisplayed until the next time doupdate happens to be called. This problem can be seen in PR gdb/32623. When an inferior is started the 'Starting program' message is not immediately displayed to the user. The 'Starting program' message originates from run_command_1 in infcmd.c, the message is sent to the current_uiout, which will be the TUI ui_out. After the message is sent, ui_out::flush() is called, here's the backtrace when that happens: #0 tui_file::flush (this=3D0x36e4ab0) at ../../src/gdb/tui/tui-file.= c:42 #1 0x0000000001004f4b in pager_file::flush (this=3D0x36d35f0) at ../../src/gdb/utils.c:1531 #2 0x0000000001004f71 in gdb_flush (stream=3D0x36d35f0) at ../../src/gdb/utils.c:1539 #3 0x00000000006975ab in cli_ui_out::do_flush (this=3D0x35a50b0) at ../../src/gdb/cli-out.c:250 #4 0x00000000009fd1f9 in ui_out::flush (this=3D0x35a50b0) at ../../src/gdb/ui-out.h:263 #5 0x00000000009f56ad in run_command_1 (args=3D0x0, from_tty=3D1, run_how=3DRUN_NORMAL) at ../../src/gdb/infcmd.c:449 #6 0x00000000009f599a in run_command (args=3D0x0, from_tty=3D1) at ../../src/gdb/infcmd.c:511 And if we check out tui_file::flush (tui-file.c) we can see that this just calls tui_win_info::refresh_window(), which in turn, just uses wnoutrefresh to batch any pending output. The problem is that, in the above backtrace, there is no tui_batch_rendering active, and so there will be no doupdate call to flush the output to the screen. We could add a tui_batch_rendering into tui_file::flush. And tui_file::write. And tui_file::puts ..... ... but that all seems a bit unnecessary. Instead, I propose that tui_win_info::refresh_window() should be changed. If suppress_output is true (i.e. a tui_batch_rendering is active) then we should continue to call wnoutrefresh(). But if suppress_output is false, meaning that no tui_batch_rendering is in place, then we should call wrefresh(), which immediately writes the output to the screen. Testing but PR gdb/32623 was a little involved. We need to 'run' the inferior and check for the 'Starting program' message. But DejaGNUU can only check for the message once it knows the message should have appeared. But, as the bug is that output is not displayed, we don't have any output hints that the inferior is started yet... In the end, I have the inferior create a file in the test's output directory. Now DejaGNU can send the 'run' command, and wait for the file to appear. Once that happens, we know that the 'Starting program' message should have appeared. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=3D32623 Approved-By: Tom Tromey --=20 You are receiving this mail because: You are on the CC list for the bug.=