Re: New FAILs on gdb.tui/empty.exp

[Tom Tromey <tom at tromey dot com>]

>>>>> "Sergio" == Sergio Durigan Junior <sergiodj@redhat.com> writes:

>> PASS -> FAIL: gdb.tui/empty.exp: asm-regs: 80x24: box 1

Sergio> I forgot to say, but these seem to be racy; they go from UNRESOLVED to
Sergio> FAIL and back to UNRESOLVED, apparently.

I couldn't reproduce these with the current tree, but I can reproduce
various failures with other patches of mine.

I dug into this and it was a zany adventure.

First, empty.exp is just wrong in parts, which I didn't notice when I
wrote it.  In particular, the test for text appearing in the window does
not work -- you can change the text to anything and it will still pass.

I hacked tuiterm to dump the screen on every event, which was also
educational.  I saw weird redraws, where it looked like the window size
was somehow wrong.  This lead me into the expect source code, where I
discovered it processes "stty" arguments in order -- i.e., there are two
window size changes, not a single one as you'd expect.  So, gdb sees
SIGWINCH twice, but because tuiterm doesn't know this, it results in
apparently weird redraws.

I really went down the rabbit-hole on this, trying to find a way for the
terminal to reliably decide "gdb thinks the resize is done".  I haven't
yet found a non-racy way to make this work, but the closest has been a
special "maint set" that tells gdb to print a message with a "resize
serial number" after each SIGWINCH.

Considering that I have ~50 more TUI patches in the queue, and that
fixing this particular race is hard, I think what I would like to do is
disable this test for the time being, and then fix it once the
refactorings are in.  My logic here is (a) laziness but also (b) the
refactorings make it substantially simpler to find and fix weird
behavior in the TUI.  Here in particular I'm thinking of tracking down
some extra complete screen redraws that I see.

Let me know what you think.  Also, I welcome ideas about making the
terminal implementation reliably detect "gdb is done".

Tom