When run interactively, this test reliably passes. But when run via the vttest automation script it doesn't reliably pass - in certain circumstances it produces output that looks like a character is going missing on line wrap:
(DECOM off, DECLRMM off, top half, left half)
Observations:
- If the test is the first test to run then it passes.
- If its run twice back to back, the first one passes and the second one fails.
- If the test is run slowly (eg,
set input pacing 1), then it passes.
- If I replay a recorded session log of the test, it passes regardless of whether its run slowly or not
- If I replay a recorded session log of the test in the background (while on the command screen, using the
input /nomatch 5 to just process input for 5 seconds), it fails but in a rather different way - the result is similar to if you just cat the session log in a terminal. I'm not sure why catting the session log doesn't work, but that at least isn't a K95-specific issue - it doesn't work in other terminals either.
- If the debugger is attached, it passes. Though the tests also also take an extra 15 seconds, so this might just be the running slowly thing again
- Protocol doesn't matter - SSH and Telnet both fail the same
- If instead of running the test off-screen, the script selects the test and then immediately switches to the terminal screen, it passes (
lineout 13 followed by connect to switch from the command screen back to the terminal screen).
The test itself isn't doing anything exciting - there are no control sequences embedded in the string of numbers, so its just line wrapping that is somehow going wrong.
I see a few possibilities:
- Some timing issue/race condition somewhere
- This is a nearly 40 year old mostly ANSI C codebase, so... memory error somewhere?
- Ideally: some issue with the way the test is being run - the
input command.
Normally when on the command screen, K95 isn't processing input from the network - the terminal emulator is paused. The input command is used for watching the input stream for certain strings in order to automate terminal applications (similar to expect scripts) - whenever it takes a byte from the network/serial port/whatever to do its job, it passes that byte onwards to the terminal emulator. So while the input command is searching the input stream for some string, the terminal emulator is also kind of active - its processing input and updating the screen buffer, but its not in connect mode and the terminal isn't visible on screen.
So, maybe there is a bug somewhere in the input command? All occurrences of the test failing have been while the input command was feeding data to the terminal emulator, rather than the terminal emulator running freely...
When run interactively, this test reliably passes. But when run via the vttest automation script it doesn't reliably pass - in certain circumstances it produces output that looks like a character is going missing on line wrap:
(DECOM off, DECLRMM off, top half, left half)
Observations:
set input pacing 1), then it passes.input /nomatch 5to just process input for 5 seconds), it fails but in a rather different way - the result is similar to if you just cat the session log in a terminal. I'm not sure why catting the session log doesn't work, but that at least isn't a K95-specific issue - it doesn't work in other terminals either.lineout 13followed byconnectto switch from the command screen back to the terminal screen).The test itself isn't doing anything exciting - there are no control sequences embedded in the string of numbers, so its just line wrapping that is somehow going wrong.
I see a few possibilities:
inputcommand.Normally when on the command screen, K95 isn't processing input from the network - the terminal emulator is paused. The
inputcommand is used for watching the input stream for certain strings in order to automate terminal applications (similar to expect scripts) - whenever it takes a byte from the network/serial port/whatever to do its job, it passes that byte onwards to the terminal emulator. So while theinputcommand is searching the input stream for some string, the terminal emulator is also kind of active - its processing input and updating the screen buffer, but its not in connect mode and the terminal isn't visible on screen.So, maybe there is a bug somewhere in the input command? All occurrences of the test failing have been while the input command was feeding data to the terminal emulator, rather than the terminal emulator running freely...