test_winconsoleio fails and hangs on Windows #85895
Comments
|
f:\dev\3x>python -m test test.test_winconsoleio ---- Victor's patch for bpo-38325 skipped the tests that failed on Windows, but now the overall test is worse. One must interrupt with ^C to get the test summary for the suite. |
terryjreedy
added
3.8 (EOL)
|
Running test -v test_winconsoleio showed that the hang is in test_cntl_z. With that commented out, I get failures in test_input (1st assert) and test_partial_reads and some bizarre console behavior. F:\dev\3x>python -m test -v test_winconsoleio ====================================================================== Traceback (most recent call last):
File "f:\dev\3x\lib\test\test_winconsoleio.py", line 142, in test_input
self.assertStdinRoundTrip('abc123')
File "f:\dev\3x\lib\test\test_winconsoleio.py", line 138, in assertStdinRoundTrip
self.assertEqual(actual, text)
AssertionError: 'aaaaaaaaaabbbbbbbbbbcccccccccc111111111122222222223333333333' != 'abc123'
- aaaaaaaaaabbbbbbbbbbcccccccccc111111111122222222223333333333
+ abc123====================================================================== Traceback (most recent call last):
File "f:\dev\3x\lib\test\test_winconsoleio.py", line 168, in test_partial_reads
self.assertEqual(actual, expected, 'stdin.read({})'.format(read_count))
AssertionError: b'\r\n' != b'\xcf\xbc\xd1\x9e\xd0\xa2\xce\xbb\xd0\xa4\xd0\x99\r\n' : stdin.read(1)Ran 10 tests in 0.019s FAILED (failures=2, skipped=2) == Tests result: FAILURE == 1 test failed: Total duration: 266 ms F:\dev\3x> F:\dev\3x> Even though behavior is the same in 3 different workspaces, and the file shows no obvious sign of corruption in Notepad++, I deleted it anyway (in master) with Windows Explorer 'delete' (not git delete) and then reverted the change. Still, someone should verify that this is not just my machine. Note that I just got the 2008 updates (last Tuesday?) to Win 10, 2004, some of which were apparently optional at the moment. |
I don't know why Steve made write_input (PC/_testconsole.c) set wRepeatCount in each KeyEvent record to 10. Maybe it was a typo. Previous console implementations have ignored the repeat count, so it wasn't an issue. test_ctrl_z checks (1) that reading a non-ASCII character works when split across two reads and (2) that Ctrl+Z (0x1A) as the first character of a read is handled as EOF, regardless of where it occurs on the line as long as it's the first character in the buffer. The latter has to be tested because _WindowsConsoleIO has to manually implement the way that WinAPI ReadFile handles Ctrl+Z, a behavior that WinAPI ReadConsoleW does not itself implement. |
|
After splitting the two reads onto two lines, the indefinite hang happens in the second one, stdin.readall. def test_ctrl_z(self):
with open('CONIN$', 'rb', buffering=0) as stdin:
source = '\xC4\x1A\r\n'.encode('utf-16-le')
expected = '\xC4'.encode('utf-8')
print('here')
write_input(stdin, source)
a = stdin.read(1)
## b = stdin.readall()
self.assertEqual(expected[0:1], a)
## self.assertEqual(expected[1:], b)The resulting failure of the first assertion results in: Traceback (most recent call last):
File "F:\dev\3x\lib\test\test_winconsoleio.py", line 197, in test_ctrl_z
self.assertEqual(expected[0:1], a)
AssertionError: b'\xc3' != b'\r'This minimal change would stop the hang crash, which is the first priority. However, changing the repeat from 10 to 1, to look like fixes all failures, including the hang. I will submit for CI testing. Is this line needed with a repeat of 1, or should it be removed? Also, this file has a section added by arg clinic. Does it need to be regenerated for this change? If so, how? |
It's not documented what it means to write a key event with wRepeatCount set to 0. It happens to work, but I'd leave it set to 1, which means the key was pressed once. Ideally, there should also be a subsequent key-up event that's the same except bKeyDown is FALSE, but test_winconsoleio doesn't need it. |
|
I was assuming that the default was 1, not 0. But now that CI tests pass code as is, I will leave it alone. |
|
Steve, as author of the file and line in question, do you have any objection to changing it? |
|
No objections. I'd guess it was a typo. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: