[Bug tui/32623] New: TUI console window doesn't update while inferior is running

[Bug tui/32623] New: TUI console window doesn't update while inferior is running

[ssbssa at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32623

            Bug ID: 32623
           Summary: TUI console window doesn't update while inferior is
                    running
           Product: gdb
           Version: 16.1
            Status: NEW
          Severity: normal
          Priority: P2
         Component: tui
          Assignee: unassigned at sourceware dot org
          Reporter: ssbssa at sourceware dot org
  Target Milestone: ---

Using this test program:
```
#include <thread>

void pause()
{
  std::this_thread::sleep_for(std::chrono::seconds(3));
}

int main()
{
  std::thread thread(pause);
  thread.join();
}
```

Without TUI mode, while the program is running, it looks something like this:
```
(gdb) run
Starting program: C:\src\tests\sleeper.exe
[New Thread 4708.0x2b74]
```

But in TUI mode, there is nothing visible after `run`:
```
(gdb) run
```

And once the program finishes, everything appears:
```
Starting program: C:\src\tests\sleeper.exe
[New Thread 9748.0x22a8]
[Thread 9748.0x22a8 exited with code 0]
[Inferior 1 (process 9748) exited normally]
(gdb)
```

I think it started with [1], because inside tui_wrefresh it changed wrefresh
to wnoutrefresh, so tui_file::flush no longer flushes to the screen.


[1]
https://sourceware.org/cgit/binutils-gdb/commit/?id=d3acf3d759d085df544687b39a0c2900d3117bf7

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tui/32623] TUI console window doesn't update while inferior is running

[aburgess at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32623

Andrew Burgess <aburgess at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aburgess at redhat dot com
   Target Milestone|---                         |16.3

--- Comment #1 from Andrew Burgess <aburgess at redhat dot com> ---
Setting milestone to 16.3 as this is a regression from the 15.x release.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tui/32623] TUI console window doesn't update while inferior is running

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32623

--- Comment #2 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4f28b020a3416ac87ac12cf7ae3625a4bc178975

commit 4f28b020a3416ac87ac12cf7ae3625a4bc178975
Author: Andrew Burgess <aburgess@redhat.com>
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=0x36e4ab0) at ../../src/gdb/tui/tui-file.c:42
      #1  0x0000000001004f4b in pager_file::flush (this=0x36d35f0) at
../../src/gdb/utils.c:1531
      #2  0x0000000001004f71 in gdb_flush (stream=0x36d35f0) at
../../src/gdb/utils.c:1539
      #3  0x00000000006975ab in cli_ui_out::do_flush (this=0x35a50b0) at
../../src/gdb/cli-out.c:250
      #4  0x00000000009fd1f9 in ui_out::flush (this=0x35a50b0) at
../../src/gdb/ui-out.h:263
      #5  0x00000000009f56ad in run_command_1 (args=0x0, from_tty=1,
run_how=RUN_NORMAL) at ../../src/gdb/infcmd.c:449
      #6  0x00000000009f599a in run_command (args=0x0, from_tty=1) 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=32623

    Approved-By: Tom Tromey <tom@tromey.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tui/32623] TUI console window doesn't update while inferior is running

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=32623

--- Comment #3 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The gdb-16-branch branch has been updated by Andrew Burgess
<aburgess@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=2b646bb87677b206af8f88f132a12a4181b6e356

commit 2b646bb87677b206af8f88f132a12a4181b6e356
Author: Andrew Burgess <aburgess@redhat.com>
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=0x36e4ab0) at ../../src/gdb/tui/tui-file.c:42
      #1  0x0000000001004f4b in pager_file::flush (this=0x36d35f0) at
../../src/gdb/utils.c:1531
      #2  0x0000000001004f71 in gdb_flush (stream=0x36d35f0) at
../../src/gdb/utils.c:1539
      #3  0x00000000006975ab in cli_ui_out::do_flush (this=0x35a50b0) at
../../src/gdb/cli-out.c:250
      #4  0x00000000009fd1f9 in ui_out::flush (this=0x35a50b0) at
../../src/gdb/ui-out.h:263
      #5  0x00000000009f56ad in run_command_1 (args=0x0, from_tty=1,
run_how=RUN_NORMAL) at ../../src/gdb/infcmd.c:449
      #6  0x00000000009f599a in run_command (args=0x0, from_tty=1) 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=32623

    Approved-By: Tom Tromey <tom@tromey.com>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug tui/32623] TUI console window doesn't update while inferior is running

[aburgess at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=32623

Andrew Burgess <aburgess at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Andrew Burgess <aburgess at redhat dot com> ---
Should now be fixed in master, and the gdb-16-branch for a possible 16.3
release.

-- 
You are receiving this mail because:
You are on the CC list for the bug.