Error with console output in Python 3.6 on Windows #103
Comments
|
+1. The same happens to me, with pytest 3.0.5, python 3.6.0 release (= RC 2) on Windows 8 |
|
same error in windows 7 with python36: when using read() or readlines() to read the content of a file.txt containing UTF8 characters
a= text.readlines()
a= text.read()
|
|
Same error on Windows 10 with Python 3.6.0.final.0 when trying to print to the console. This previously had worked fine in Python 3.5. |
|
this looks like python 3.6 broke colorama - at first glace i believe tartley/colorama#121 needs to get merged and released |
|
a potential workaround may be to uninstall colorama, can a windows user verify if that holds up? |
|
I just uninstalled colorama and tried to re-run my tests, but got the same error as before. |
|
My current workaround is piping the output into a file as that avoids the error. |
|
+1 with 3.6.0 & Windows Server 2016 |
|
Same error with 3.6.1 & Windows 10 Education build 14393. And just like @gboeing , when I uninstalled |
|
Note that the error occurs even though pytest is not attempting to print any non-ASCII characters (in fact, the particular character on which this happens is a dot). Can anyone replicate this reliably without pytest? |
|
I tried to debug this horror. It wasn't pretty... 😭 The error really originates from The real error appears to be But why in the world would it only close it randomly?! Despite calling Anyhow... What I think is the real issue here is that now Python is writing directly to an Yet I still don't understand why it's random... 😕 Also note issue on colorama: tartley/colorama#119 |
|
I'm not sure where the code for |
|
@pkch I think it's this posixmodule.c:7822-7835. It might be calling the msvcrt/ucrt dup2 (Maybe with an underscore) you can see it's code in the ucrt sources in the Windows SDK. I might check later if it's really this one. |
|
Setting |
Python 3.6 implemented unicode console handling for Windows. This works
by reading/writing to the raw console handle using
``{Read,Write}ConsoleW``.
The problem is that we are going to ``dup2`` over the stdio file
descriptors when doing ``FDCapture`` and this will ``CloseHandle`` the
handles used by Python to write to the console. Though there is still some
weirdness and the console handle seems to only be closed randomly and not
on the first call to ``CloseHandle``, or maybe it gets reopened with the
same handle value when we suspend capturing.
The workaround in this case will reopen stdio with a different fd which
also means a different handle by replicating the logic in
"Py_lifecycle.c:initstdio/create_stdio".
See pytest-dev/py#103
|
Fixed by pytest-dev/pytest#2462 |
|
This is happening to me when I run pytest from the command line with the specs: platform win32 -- Python 3.6.1, pytest-3.0.7, py-1.4.33, pluggy-0.4.0. Strangely, it only occurs on some of the runs. Sometimes it will fail and throw the giant stack trace, and some times it will succeed just fine. It has NOT occurred when I run in PyCharm however. |
|
@pwaivers The fix was part of pytest 3.1.2, the latest release is 3.2.3. You might want to upgrade. |
… Python 3.6+ with colorama - pytest-dev/py#103
|
Solved . !!!!! |
|
Thanks for following up |
|
Hi, I'm using a clean Python 3.7 installation on Windows 7 and get this WinError 87 :( |
I got the same problem with 3.7.4 and pytest clean environment |
|
@oholimoli @siben168 |
|
According to #103 (comment) it might be due to an encoding issue even. |
Yes, this is an issue for pytest, I have submitted an issue for pytest. Thanks! |
|
It sounds like this issue needs to be reopened. I'm seeing the same thing with a fresh Python 3.7 venv on Windows when I simply run |
When running pytest in Python 3.6rc2 on Windows, there seems to be a problem with formatting the console output. The tests run fine until at some point it crashes because of a
OSError: [WinError 87] The parameter is incorrect. This does not happen if I pipe the output into a file instead of having it in the console. I am not sure whether that is an issue with thepy._io.TerminalWriteror something else. Since the 3.6 version is also not stable yet, so the issue might be there.This is the trace back I am getting:
The text was updated successfully, but these errors were encountered: