I've been playing around with TUI, and tried to find an easy way to do a stress test.

I came up with starting a hello world, and doing si and then keeping my finger on the enter key and see what happens.

I eventually ran into screen garbling, which could be repaired using ^L.

I realized this garbling could be the result of printing the "hello", so I moved to compiling "int main (void) { return 0; }", doing a starti, and stepi-ing from there.  I played around with this for a while, and found that I could reproduce the problem within minutes when starting to stepi from __GI___tunables_init.

I tried to write a test-case that mimics this in the testsuite, but sofar I didn't manage to reproduce this.

So, here are the steps I followed (this may be way over-specific):
- openSUSE Leap 15.4 x86_64-linux
- gdb build using -O0
- gdb build from commit 38b95a52938 ("Automatic date update in version.in")
- gnome-terminal (on KDE desktop)
- TERM=xterm (native TERM=xterm-256colors)
- tab with COLUMNS 145, LINES 37
- stay in the tab, to avoid ncurses refresh when switching back to the tab.
  This also prevents resetting the regs window layout to one reg on one line.
- gdb started using "gdb ~/a.out"
- starti
- layout asm (enter tui, use asm window)
- layout regs (add regs window)
- stepi (populate regs window, should show two regs on one line)
- b __GI___tunables_init, continue
- stepi (command to repeat)
- press-and-hold enter
- observe garbling and release enter (for me, after about 3/4 minutes)

I've now also reproduce by starting gdb like so:
...
$ gdb -q ~/a.out \
    -ex "starti" \
    -ex "layout asm" \
    -ex "layout regs" \
    -ex "stepi" 
    -ex "b __GI___tunables_init" 
... 
and then continue, stepi, and press-and-hold enter.