[miss-islington]

(cherry picked from commit 3abc03c)

Co-authored-by: AN Long aisk@users.noreply.github.com

• Issue: Wrong use of ctypes.GetLastError() in windows_console.py #132888

[picnixz]

@mishulantis does this solve your issue?

[vstinner]

LGTM

[vstinner]

test_socket failed on Sanitizers / MSan:

ERROR: testSourceAddress (test.test_socket.NetworkConnectionAttributesTest.testSourceAddress)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/runner/work/cpython/cpython/Lib/test/test_socket.py", line 447, in raise_queued_exception
    raise self.queue.get()
  File "/home/runner/work/cpython/cpython/Lib/test/test_socket.py", line 484, in clientRun
    test_func()
    ~~~~~~~~~^^
  File "/home/runner/work/cpython/cpython/Lib/test/test_socket.py", line 6061, in _testSourceAddress
    self.assertEqual(self.cli.getsockname()[1], self.source_port)
                     ~~~~~~~~~~~~~~~~~~~~^^
OSError: [Errno 9] Bad file descriptor

This failure is unrelated to the change. I re-run the MSan job.

[mishulantis]

Yes, the backport resolves my original Windows NUL + pipe reproducer when its changes are loaded. I tested on Windows 11 build 26200 with CPython 3.14.3 x64 and Git for Windows 2.56.0.windows.4 (Bash 5.3.15).

I ran python - with an empty Git Bash heredoc, with Git Bash </dev/null, and with native Windows NUL assigned directly to stdin. In each case stdout and stderr were captured in pipes. The handle probes reported isatty(0) == True, GetFileType(stdin) == FILE_TYPE_CHAR, and GetConsoleMode(stdin) failing with error 6.

Case	Original 3.14.3	Same executable with the #161633 module changes
Empty Git Bash heredoc	Repeated WinError 123 tracebacks, stopped at 1 MiB	Python exited 0
Git Bash </dev/null	Repeated WinError 123 tracebacks, stopped at 1 MiB	Python exited 0
Direct Windows NUL	Repeated WinError 123 tracebacks, stopped at 1 MiB	Python exited 0

The patched runs issued one PyREPL fallback warning with WinError 6, then exited without tracebacks. The unchanged-source overlay control still reproduced in all three cases. I applied the changes from 576f556e8180dffcfd934cc3540cea4cdb7a4d85 to an isolated copy of _pyrepl/windows_console.py, then selected that copy only in the test children. The installed standard library remains stock 3.14.3. Every test used a 5-second watchdog, a 1 MiB combined read limit, and a Windows Job Object. The Job had no remaining processes after each case.

I also verified that PYTHON_BASIC_REPL=1, which is configured in my local Claude Code user settings, prevents the loop in all three cases with the installed Python. The official-backport comparison ran with that setting unset.