WinError 6, the handle is invalid about win-unicode-console HOT 11 CLOSED

A simple test that gives 100% repro on Python 2.7.11 (AMD64):

import win_unicode_console
from multiprocessing.pool import ThreadPool

def f(x):
    print(x)

if __name__ == '__main__':
    win_unicode_console.enable()
    p = ThreadPool(1)
    p.map(f, range(10))

from win-unicode-console.

Are there any special conditions when running Python in the non-working case? Isn't Python IDLE run in the second case?

By the last sentence you mean that win_unicode_console 0.4 works fine on his computer? If so, in which way 0.5 doesn't?

from win-unicode-console.

I guess you are right, the result looks weird on my IDLE too (but why?). I will ask him to test again. Following is what actually happened.

I have created a little package called safeprint, which writes data to win_unicode_console.streams.stdout_text_transcoded:
https://github.com/eight04/safeprint/blob/master/safeprint/__init__.py#L71
And someone told me that it doesn't work with win-unicode-console 0.5 which works well on my computer. Here is the stack trace:

Microsoft Windows [版本 6.1.7600]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\Kin>comiccrawler gui
Traceback (most recent call last):
  File "C:\Python34\lib\runpy.py", line 170, in _run_module_as_main
    "__main__", mod_spec)
  File "C:\Python34\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Python34\Scripts\comiccrawler.exe\__main__.py", line 9, in <module>
  File "C:\Python34\lib\site-packages\comiccrawler\__init__.py", line 49, in con
sole_init
    MainWindow()
  File "C:\Python34\lib\site-packages\comiccrawler\gui.py", line 177, in __init_
_
    download_manager.start_check_update()
  File "C:\Python34\lib\site-packages\comiccrawler\download_manager.py", line 18
7, in start_check_update
    self.do_check_update()
  File "C:\Python34\lib\site-packages\comiccrawler\download_manager.py", line 19
8, in do_check_update
    print("Update checking done")
  File "C:\Python34\lib\site-packages\safeprint\__init__.py", line 27, in print
    self.imp_print(text, end=end)
  File "C:\Python34\lib\site-packages\safeprint\__init__.py", line 71, in imp_pr
int
    print(text, end=end, file=win_unicode_console.streams.stdout_text_transcoded
)
  File "C:\Python34\lib\site-packages\safeprint\__init__.py", line 25, in print
    builtins.print(text, end=end, file=file, flush=flush)
  File "C:\Python34\lib\site-packages\win_unicode_console\streams.py", line 216,
 in write
    return self.base.write(s)
  File "C:\Python34\lib\site-packages\win_unicode_console\streams.py", line 165,
 in write
    raise exc
OSError: [WinError 6] 控制代碼無效。

0.4 works well for him.

from win-unicode-console.

It is incorrect to print unconditionally to a win_unicode_console stream, the file may be redirected or there may be no stdout at all like in IDLE or you may even not be on Windows. win_unicode_console performs a check to decide whether to change the streams and which streams to use. This is not trivial. In IDLE, the streams shouldn't be changed, you are not in a console environment and there is actually no problem with printing Unicode characters in IDLE.

from win-unicode-console.

The latest result:

Python 3.4.3 (v3.4.3:9b73f1c3e601, Feb 24 2015, 22:44:40) [MSC v.1600 64 bit (AM
D64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import msvcrt
>>> print(msvcrt.get_osfhandle(1))
7
>>>
>>> from ctypes import windll
>>> print(windll.kernel32.GetStdHandle(-11))
7
>>>

Looks like it's not the problem with msvcrt.get_osfhandle.

Do you have any idea why version 0.5 cause WinError 6? or maybe it failed with 0.4 but not raising?

from win-unicode-console.

P.S. the text is correctly printed with version 0.4.

from win-unicode-console.

The big number msvcrt.get_osfhandle sometimes returns is -2 + 2**64 and in this situation, GetStdHandle returns 0. That happens when there is no corresponing handle at all like in a GUI application. If you are in IDLE, you cannot use win_unicode_console to print anything since there is no console. In this situation printing to win_unicode_console.streams.stdout_text should always raise an error (and it does for me with both 0.4 and 0.5). The error message(s) should be improved though.

from win-unicode-console.

After some tests, I found that it works if I call streams.STDOUT.should_be_fixed() (calling GetConsoleMode) before writing text into streams.stdout_text_transcoded, but I don't know why.

from win-unicode-console.

I still don't precisely know under what conditions it doesn't work for you. I only know it doesn't work in IDLE where it shouldn't work. When there is no stdio, GetConsoleMode should raise invalid handle, streams.STDOUT.should_be_fixed() should return False and streams.stdout_text_transcoded shouldn't be used at all.

from win-unicode-console.

Use Windows 7 + Python 3.4.4 64bit with following code:

import sys
print(sys.version)

from win_unicode_console import streams
print("test", file=streams.stdout_text_transcoded)

It randomly raises OSError (yes, sometime it works fine):

C:\Users\Owner\Desktop>py -3.4 test.py
3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 20:20:57) [MSC v.1600 64 bit (AMD64)]
test

C:\Users\Owner\Desktop>py -3.4 test.py
3.4.4 (v3.4.4:737efcadf5a6, Dec 20 2015, 20:20:57) [MSC v.1600 64 bit (AMD64)]
Traceback (most recent call last):
  File "test.py", line 5, in <module>
    print("test", file=streams.stdout_text_transcoded)
  File "C:\Python34\lib\site-packages\win_unicode_console\streams.py", line 216,
 in write
    return self.base.write(s)
  File "C:\Python34\lib\site-packages\win_unicode_console\streams.py", line 165,
 in write
    raise exc
OSError: [WinError 6] 控制代碼無效。

from win-unicode-console.

The root cause here is usage of wrong data types in some Windows API calls on 64-bit systems (as demonstrated also by the version strings in the reports above).

E.g. in WindowsConsoleRawWriter.write(), self.handle usually ends up being something low like 84. Because ctypes knows nothing about WriteConsoleW(), it guesses the data type of the first argument to be a 32-bit number.

This is wrong, because the type is really HANDLE, which is supposed to be wide as a pointer on the platform. E.g. in ctypes/wintypes, HANDLE = c_void_p. So the upper 32 bits can be left containing anything, and then error 6 (ERROR_INVALID_HANDLE) will surely be the result.

The solution is to fix the type, either by and explicit c_void_p(self.handle), or with wintypes.HANDLE, or nicely at the time of the import through WriteConsoleW.argtypes (and similar, for the other functions).

My PR (that I'll post in a few seconds) does it the latter way, like it is already done in other parts of win-unicode-console. And without referencing wintypes, to avoid the extra I/O in arguably the most common parts of the library. Of course feel free to modify/improve/fix as you see fit.

from win-unicode-console.