[Bug tui/21737] New: TUI becomes garbled when GDB is not waiting for input but receives a newline while cursor is at the bottom

[b7.10110111 at gmail dot com]

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

Bug ID: 21737
Summary: TUI becomes garbled when GDB is not waiting for input
but receives a newline while cursor is at the bottom
Product: gdb
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: tui
Assignee: unassigned at sourceware dot org
Reporter: b7.10110111 at gmail dot com
Target Milestone: ---

To reproduce:

1. Launch GDB as:

gdb -tui /bin/sleep -ex 'layout asm' -ex 'catch syscall nanosleep' -ex 'r 5'
-ex 'set pagination off' -ex 'info all-reg'

2. When the inferior stops, type "ni" followed by two or more <Return> presses
3. Notice how the console contents moved up as you pressed <Return> the second
time
4. Now after 5 seconds, when the inferior stops, the screen is partially
updated, leaving no longer valid contents in multiple places: the old (scrolled
up) highlighted current line in the disassembly window, the disassembly
(partially correct, partially scrolled), PC value in the bottom-right corner of
the disassembly window (its updated lowest digits are under the old "status
bar"), ...

[b7.10110111 at gmail dot com]

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

--- Comment #1 from Ruslan <b7.10110111 at gmail dot com> ---
Created attachment 10253
--> https://sourceware.org/bugzilla/attachment.cgi?id=10253&action=edit
How it looks after several "ni" steps because of garbling

Here is a screenshot of how the TUI looks after I repeated the "ni" command
after the inferior's syscall ended, to exit from __kernel_vsyscall.

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |tromey at sourceware dot org

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
Which terminal are you using, and what is your TERM setting?
Are you using something like screen or tmux?

My belief is that gdb is basically at the mercy of ncurses for
most things like this. Some garbling can occur when the inferior
writes to stdout/stderr, but that doesn't seem to be the case
here.

I can't reproduce this with gnome-terminal.

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2018-09-03
Ever confirmed|0 |1

[b7.10110111 at gmail dot com]

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

--- Comment #3 from Ruslan <b7.10110111 at gmail dot com> ---
(In reply to Tom Tromey from comment #2)

Post by tromey at sourceware dot org
Which terminal are you using, and what is your TERM setting?
Are you using something like screen or tmux?

I'm able to reproduce this in Konsole 2.14.2, Yakuake 2.9.9, xterm 301,
gnome-terminal 2.18.1 and in Linux VT on Linux-3.12.18.

Post by tromey at sourceware dot org
I can't reproduce this with gnome-terminal.

At which step do the results differ from what I described in comment #0? I
followed the instructions exactly and have 100% reproducibility in all the
above listed environments.

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |NEW

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
Aha, I see -- I waited for the "ni" to finish before pressing enter.
I can see the bug if I type "ni" RET RET before the sleep finishes.

I suspect this is another instance of bug 14332, because after
the command the terminal is given to the inferior.