andfoy
commented
7 years ago Actually, it seems that Windows API functions should be declared explicitly: https://github.com/asweigart/pyperclip/issues/25#issuecomment-269271886
Closed andfoy closed 6 years ago
andfoy
commented
7 years ago Actually, it seems that Windows API functions should be declared explicitly: https://github.com/asweigart/pyperclip/issues/25#issuecomment-269271886
jxrossel
commented
7 years ago Still doesn't work:
File "C:\PortableSoftware\WinPython3-6\python-3.6.2.amd64\lib\site-packages\winpty\winpty_wrapper.py", line 63, in read
ReadFile(self.conout_pipe, data, length, None, None)
OSError: exception: access violation writing 0x0000000000000000... and another error appeared in spyder after trying to open/close a terminal:
File "C:\PortableSoftware\WinPython3-6\python-3.6.2.amd64\lib\site-packages\spyder_terminal\terminalplugin.py", line 317, in <lambda>
term.terminal_closed.connect(lambda: self.close_term(term=term))
File "C:\PortableSoftware\WinPython3-6\python-3.6.2.amd64\lib\site-packages\spyder_terminal\terminalplugin.py", line 330, in close_term
term.close()
AttributeError: 'NoneType' object has no attribute 'close'
Traceback (most recent call last):
File "C:\PortableSoftware\WinPython3-6\python-3.6.2.amd64\lib\site-packages\spyder_terminal\terminalplugin.py", line 317, in <lambda>
term.terminal_closed.connect(lambda: self.close_term(term=term))
File "C:\PortableSoftware\WinPython3-6\python-3.6.2.amd64\lib\site-packages\spyder_terminal\terminalplugin.py", line 330, in close_term
term.close()
AttributeError: 'NoneType' object has no attribute 'close'I think this is an issue related to your distribution header files, I don't know what else to do on your case.
jxrossel
commented
7 years ago You mean it doesn't / won't work with WinPython as distribution ?
andfoy
commented
7 years ago @stonebig, we have a problem here, have you had more problems with Access Violation Errors?
andfoy
commented
7 years ago @jxrossel, I've just asked to the current mantainer of WinPython if he can give us some help.
stonebig
commented
7 years ago I didn't notice, but also I'm not on Windows7, and I always live in next "beta". will re-check before next beta.
Well, I can't create a second Terminal2, it freeze the Terminal1, but I don't have any problem in Terminal1.
MRGiacalone
commented
6 years ago Following Pyperclip issue https://github.com/asweigart/pyperclip/issues/25 landed on this one. My issue seems to be related to the Windows 10 clipboard
In my case I am using Passpie to copy a password to the clipboard.
Traceback (most recent call last):
File "m:\miniconda3\lib\runpy.py", line 193, in _run_module_as_main
"__main__", mod_spec)
File "m:\miniconda3\lib\runpy.py", line 85, in _run_code
exec(code, run_globals)
File "M:\Miniconda3\Scripts\passpie.exe\__main__.py", line 9, in <module>
File "m:\miniconda3\lib\site-packages\click\core.py", line 716, in __call__
return self.main(*args, **kwargs)
File "m:\miniconda3\lib\site-packages\click\core.py", line 696, in main
rv = self.invoke(ctx)
File "m:\miniconda3\lib\site-packages\click\core.py", line 1060, in invoke
return _process_result(sub_ctx.command.invoke(sub_ctx))
File "m:\miniconda3\lib\site-packages\click\core.py", line 889, in invoke
return ctx.invoke(self.callback, **ctx.params)
File "m:\miniconda3\lib\site-packages\click\core.py", line 534, in invoke
return callback(*args, **kwargs)
File "m:\miniconda3\lib\site-packages\passpie\cli.py", line 46, in wrapper
return func(*args, **kwargs)
File "m:\miniconda3\lib\site-packages\click\decorators.py", line 64, in new_func
return ctx.invoke(f, obj, *args[1:], **kwargs)
File "m:\miniconda3\lib\site-packages\click\core.py", line 534, in invoke
return callback(*args, **kwargs)
File "m:\miniconda3\lib\site-packages\passpie\cli.py", line 275, in copy
clipboard.copy(decrypted, clear)
File "m:\miniconda3\lib\site-packages\passpie\clipboard.py", line 99, in copy
_copy_windows(text, clear)
File "m:\miniconda3\lib\site-packages\passpie\clipboard.py", line 55, in _copy_windows
ctypes.cdll.msvcrt.wcscpy(ctypes.c_wchar_p(pchData), text)
OSError: exception: access violation writing 0x0000000000000000I am not using WinPython, but rather Anaconda (Miniconda) on Windows 10. Python version 3.6.2 64 bit.
Any clues as to why the OSError: occurs while trying to use the clipboard?
andfoy
commented
6 years ago According to this SO answer, this an error ocurring on some 64-bit Python Windows binaries. I'm closing this issue since I don't know how to address this. All our ctypes calls have been tested and have been found to be functional.
blink1073
commented
6 years ago It seems as if the issue has resurfaced: cf https://github.com/jupyterlab/jupyterlab/issues/3647
andfoy
commented
6 years ago @blink1073 It seems the error is still present on some x64 Windows Python distributions. AFAIK, we cannot solve this on our own account.
mingwandroid
commented
6 years ago Why not try using http://repo.msys2.org/msys/x86_64/winpty-0.4.3-1-x86_64.pkg.tar.xz which is compiled with mingw-w64 like winpty is supposed to be compiled? What are you even using this stuff for though? Why not just spawn a thread with an event loop to communicate with Python?
ccordoba12
commented
6 years ago Ray, two things:
mingwandroid
commented
6 years ago winpty cannot be compiled with Visual Studio, please read the upstream https://github.com/rprichard/winpty
I believe someone added support for using Visual Studio but the runtime is then not the expected one (VC6 runtime) and you get this error. Whether this can be fixed or not (outside of compiling it with the compilers that the author supports => which are present in the msys2 channel in the Anaconda Distribution anyway) I do not know.
Regardless of that, can you (or someone with this problem) try my suggestion?
edit: OK, I didn't spot this part:
Compiling winpty with MSVC currently requires MSVC 2013 or newer.
But I believe (given that this is a Cygwin-derived project), that the author is unlikely to use or test with MSVC and it's safer to stick to mingw-w64.
ccordoba12
commented
6 years ago Regardless of that, can you (or someone with this problem) try my suggestion?
We would need to start using the mingw toolchain to compile winpty and also pywinpty. That's easy for conda packages but how can we generate wheels with that?
mingwandroid
commented
6 years ago I don't know anything about how wheels are generated, sorry. @jjhelmus has been looking into winpty for AD recently, maybe he knows?
jjhelmus
commented
6 years ago There are conda packages winpty compiled using mingw-w64 available in the defaults channel as well as pywinpty packages built using VS 2008 for Python 2.7 and VS 2015 for Python 3.5 and 3.6.
Even using mingw-w64 to build winpty I can replicate this issue so I do not believe problem is in the toolchain used.
Wheels could be produced in the same manner as the conda packages. Use mingw-64 to compile winpty.dll, winpty-agent.exe, and winpty-debugserver.exe and then use VS 2008, VS 2010, VS 2015 to create the wheel.
blink1073
commented
6 years ago @jjhelmus, were you also using Windows 7 when you replicated this issue?
blink1073
commented
6 years ago FWIW I just tried again today on Windows 10 with the latest Miniconda for Python 3.6 and wasn't able to replicate the issue.
jjhelmus
commented
6 years ago Yes, I replicated this on Windows 7.
ccordoba12
commented
6 years ago @SimonBiggs, @dalito, are you also using Windows 7?
SimonBiggs
commented
6 years ago Yes.
SimonBiggs
commented
6 years ago System details were provided within the following issue: https://github.com/jupyterlab/jupyterlab/issues/3647
ccordoba12
commented
6 years ago Then terminals should be deactivated on Win 7 in JupyterLab, notebook and spyder-terminal. I mean, I don't see any other choice until someone finds a solution for this.
@blink1073, what do you think?
blink1073
commented
6 years ago Yeah, it looks like Windows 7 is the common thread. I don't have access to Windows 7 for testing. We could use sys.getwindowsversion().major in the spyder-terminal and the notebook repo, which would also disable JupyterLab.
blink1073
commented
6 years ago Alternatively, we could raise an ImportError in this library based on that condition, which would require no changes to notebook.
ccordoba12
commented
6 years ago Good idea! It's better to do it here to avoid other applications using pywinpty on Win 7, since it's known to generate this ugly error.
Could you take care of that @blink1073?
blink1073
commented
6 years ago Yep, coming right up!
ccordoba12
commented
6 years ago Nice! Thanks a lot!
blink1073
commented
6 years ago Can someone with Windows 7 please test the following?
from winpty import PTY
p = PTY(80,25)
p.spawn('C:\\windows\\system32\\cmd.exe')
p.close()
del p
dhirschfeld
commented
6 years ago I don't seem to be seeing this issue myself on Win7
Python 3.6.4 |Anaconda, Inc.| (default, Jan 16 2018, 10:22:32) [MSC v.1900 64 bit (AMD64)]
Type "copyright", "credits" or "license" for more information.
IPython 6.2.1 -- An enhanced Interactive Python.
In [1]: import winpty
In [2]: winpty.__version__
Out[2]: '0.5'
In [3]: from winpty import PTY
...: p = PTY(80,25)
...: p.spawn('C:\\windows\\system32\\cmd.exe')
...: p.close()
...: del p
In [3]:
In [4]: from winpty import PTY
...:
...: # Start a new winpty-agent process of size (cols, rows)
...: cols, rows = 80, 25
...: process = PTY(cols, rows)
...:
...: # Spawn a new console process, e.g., CMD
...: process.spawn(r'C:\windows\system32\cmd.exe')
...:
...: # Read console output (Unicode)
...: process.read()
...:
Out[4]: b''λ [environment]::OSVersion.Version
Major Minor Build Revision
----- ----- ----- --------
6 1 7601 65536
blink1073
commented
6 years ago @dhirschfeld, does the high level code work for you on Win 7 as well?
from winpty import PtyProcess
proc = PtyProcess.spawn('python')
proc.write('print("hello, world!")\r\n')
proc.write('exit()\r\n')
while proc.isalive():
print(proc.readline())On the first attempt I got an OSError:
>>> proc = PtyProcess.spawn('python')
OSError: [WinError 10048] Only one usage of each socket address (protocol/network address/port) is normally permittedI tried again and got the access violation:
>>> proc = PtyProcess.spawn('python')
Exception in thread Thread-2:
Traceback (most recent call last):
File "C:\Miniconda3\lib\threading.py", line 916, in _bootstrap_inner
self.run()
File "C:\Miniconda3\lib\threading.py", line 864, in run
self._target(*self._args, **self._kwargs)
File "C:\Miniconda3\lib\site-packages\winpty\ptyprocess.py", line 331, in _read_in_thread
data = pty.read(4096)
File "C:\Miniconda3\lib\site-packages\winpty\winpty_wrapper.py", line 73, in read
ReadFile(self.conout_pipe, data, length, None, None)
OSError: exception: access violation writing 0x0000000000000000...and I'm now continuing to get the access violation with that code
andfoy
commented
6 years ago @blink1073 Do we have any idea of why the low-level API is working but not the high-level? Is very counterintuitive, as the reading access is done on the low-level side. But the example given by @dhirschfeld shows that the low level access is working as expected.
Sidenote: BTW, the 32-bit wheels up to the 4.2.0 release were compiled on Windows 7 without any problems.
andfoy
commented
6 years ago @dhirschfeld After trying the high-level access, does the low-level API works for you?
dhirschfeld
commented
6 years ago Yep, seems to. Output from Python session:
>>> from winpty import PTY
>>> p = PTY(80,25)
>>> p.spawn('C:\\windows\\system32\\cmd.exe')
True
>>> p.close()
>>> del p
>>>
>>> from winpty import PtyProcess
>>> proc = PtyProcess.spawn('python')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Miniconda3\lib\site-packages\winpty\ptyprocess.py", line 114, in spawn
inst = cls(proc)
File "C:\Miniconda3\lib\site-packages\winpty\ptyprocess.py", line 49, in __init__
self._server.bind(address)
OSError: [WinError 10048] Only one usage of each socket address (protocol/network address/port) is normally permitted
>>>
>>>
>>> proc = PtyProcess.spawn('python')
Exception in thread Thread-2:
Traceback (most recent call last):
File "C:\Miniconda3\lib\threading.py", line 916, in _bootstrap_inner
self.run()
File "C:\Miniconda3\lib\threading.py", line 864, in run
self._target(*self._args, **self._kwargs)
File "C:\Miniconda3\lib\site-packages\winpty\ptyprocess.py", line 331, in _read_in_thread
data = pty.read(4096)
File "C:\Miniconda3\lib\site-packages\winpty\winpty_wrapper.py", line 73, in read
ReadFile(self.conout_pipe, data, length, None, None)
OSError: exception: access violation writing 0x0000000000000000
>>>
>>>
>>> p = PTY(80,25)
>>> p.spawn('C:\\windows\\system32\\cmd.exe')
True
>>> p.close()
>>> del pAh, my mistake. The low level code I posted doesn't attempt to read. It should be:
from winpty import PTY
p = PTY(80,25)
p.spawn('C:\\windows\\system32\\cmd.exe')
p.read()
p.close()
del pHere are the results from a Windows 7 VM using the packages from conda-forge
Python 3.6.4 | packaged by conda-forge | (default, Dec 24 2017, 10:11:43) [MSC v
.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from winpty import PTY
>>> p = PTY(80,25)
>>> p.spawn('C:\\windows\\system32\\cmd.exe')
True
>>> p.read()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Users\builder\Anaconda3\envs\test_winpty\lib\site-packages\winpty\win
pty_wrapper.py", line 73, in read
ReadFile(self.conout_pipe, data, length, None, None)
OSError: exception: access violation writing 0x0000000000000000Python 3.6.4 | packaged by conda-forge | (default, Dec 24 2017, 10:11:43) [MSC v
.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from winpty import PtyProcess
>>> proc = PtyProcess.spawn('python')
>>> Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Users\builder\Anaconda3\envs\test_winpty\lib\threading.py", line 916,
in _bootstrap_inner
self.run()
File "C:\Users\builder\Anaconda3\envs\test_winpty\lib\threading.py", line 864,
in run
self._target(*self._args, **self._kwargs)
File "C:\Users\builder\Anaconda3\envs\test_winpty\lib\site-packages\winpty\pty
process.py", line 331, in _read_in_thread
data = pty.read(4096)
File "C:\Users\builder\Anaconda3\envs\test_winpty\lib\site-packages\winpty\win
pty_wrapper.py", line 73, in read
ReadFile(self.conout_pipe, data, length, None, None)
OSError: exception: access violation writing 0x0000000000000000The same results are seen with the packages from the defaults channel.
dalito
commented
6 years ago On Windows7 Pro 64bit, SP1:
Python 3.6.4 (v3.6.4:d48eceb, Dec 19 2017, 06:54:40) [MSC v.1900 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import winpty
>>> winpty.__version__
'0.5.1'
>>> from winpty import PTY
>>> p = PTY(80,25)
>>> p.spawn('C:\\windows\\system32\\cmd.exe')
True
>>> p.read()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "c:\dev_src\_pyve\stable_py36\lib\site-packages\winpty\winpty_wrapper.py", line 73, in read
ReadFile(self.conout_pipe, data, length, None, None)
OSError: exception: access violation writing 0x0000000000000000
>>> p.close()
>>> del pAnd how about this? We'd raise an import error if not valid:
from winpty import PTY
p = PTY(80,25)
valid = False
p.spawn('C:\\windows\\system32\\cmd.exe')
try:
p.read()
valid = True
except OSError:
pass
p.close()
del p
print('valid?', valid)>>> from winpty import PTY
>>> p = PTY(80,25)
>>> valid = False
>>> p.spawn('C:\\windows\\system32\\cmd.exe')
True
>>> try:
... p.read()
... valid = True
... except OSError:
... pass
... p.close()
File "<stdin>", line 6
p.close()
^
SyntaxError: invalid syntax
>>> del p
>>> print('valid?', valid)
valid? False
Calling p.read() does give the access violation:
>>> from winpty import PTY
>>> p = PTY(80,25)
>>> p.spawn('C:\\windows\\system32\\cmd.exe')
True
>>> p.read()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "C:\Miniconda3\lib\site-packages\winpty\winpty_wrapper.py", line 73, in read
ReadFile(self.conout_pipe, data, length, None, None)
OSError: exception: access violation writing 0x0000000000000000
>>> p.read()
b''
>>> p.close()
>>> del pThe latter test results in valid=False for me:
>>> from winpty import PTY
>>> p = PTY(80,25)
>>> valid = False
>>> p.spawn('C:\\windows\\system32\\cmd.exe')
True
>>> try:
... p.read()
... valid = True
... except OSError:
... pass
...
>>> p.close()
>>> del p
>>> print('valid?', valid)
valid? False
nurp
commented
6 years ago I can't even import winpty on Windows7 with python 3.5.4. I only wanted to run "jupyter notebook" but maybe this error is not a problem?
C:\Users\nurp\jupy>python
Python 3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:07:06) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from winpty import PTY
Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Python\Python35-32\lib\threading.py", line 914, in _bootstrap_inner
self.run()
File "C:\Python\Python35-32\lib\threading.py", line 862, in run
self._target(*self._args, **self._kwargs)
File "C:\Python\Python35-32\lib\site-packages\winpty\ptyprocess.py", line 331, in _read_in_thread
data = pty.read(4096, blocking=True)
File "C:\Python\Python35-32\lib\site-packages\winpty\winpty_wrapper.py", line 74, in read
ReadFile(self.conout_pipe, data, length, None, None)
OSError: exception: access violation writing 0x00000000.......... same message replicated for 10 threads
C:\Users\nurp\jupy>python
Python 3.5.4 (v3.5.4:3f56838, Aug 8 2017, 02:07:06) [MSC v.1900 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from winpty import PTY
Exception in thread Thread-1:
Traceback (most recent call last):
File "C:\Python\Python35-32\lib\threading.py", line 914, in _bootstrap_inner
self.run()
File "C:\Python\Python35-32\lib\threading.py", line 862, in run
self._target(*self._args, **self._kwargs)
File "C:\Python\Python35-32\lib\site-packages\winpty\ptyprocess.py", line 331, in _read_in_thread
data = pty.read(4096, blocking=True)
File "C:\Python\Python35-32\lib\site-packages\winpty\winpty_wrapper.py", line 74, in read
ReadFile(self.conout_pipe, data, length, None, None)
OSError: exception: access violation writing 0x00000000@nurp Thanks for the report, We've just merged a definitive solution for this issue on https://github.com/spyder-ide/pywinpty/issues/108 and we expect to publish a hotfix release today.
@jxrossel commented on Wed Oct 04 2017
Description of your problem
When starting spyder, I get an error message with "Terminal server could not be located (...)" and something about starting spyder in debugging mode (which I don't know how to do).
What steps will reproduce the problem?
What is the expected output? What do you see instead? error message and no terminal in the consoles
Please provide any additional information below
Versions and main components
pip list
@andfoy commented on Wed Oct 04 2017
Hi @jxrossel, to start Spyder on debugging mode you must need to set the
SPYDER_DEVvariable, as it follows, the following commands must be executed from a system terminal, which corresponds tocmd.exeon Windows:After the execution, the file
spyder_terminal_err.logmust appear on your current working directory, which is this case must be the directory of the current terminal. Please post the contents of this file, so we can help you to trace the error.@jxrossel commented on Thu Oct 05 2017
Hi, when starting spyder like that, I first had another error message "The Jupyter Notebook server failed to start..." and then the same message as above. The error log doesn't seem very helpful:
I then tried to open a new terminal in spyder, and the error log became:
The prompt in the terminal doesn't respond though
@andfoy commented on Thu Oct 05 2017
@jxrossel, can you open a browser tab on the server URL, as shown on the log file? On this case, 127.0.0.1:8071? Does a terminal appears there?
Also, I invite you to open an issue on spyder-notebook if you have notebook-related issues.
@jxrossel commented on Thu Oct 05 2017
Thanks for the answer, but pywinpty v0.2.1 is the last available version on pypi and its the one I have, so I can't update it...
I've stopped doing blind upgrades (with -U) since it tends to break installations (typically when upgrading a package which depends on the upgrade of another compiled package whose compilation fails...). Usually, I do a 2-step upgrade (with -U --no-deps first, then a simple install)
@jxrossel commented on Thu Oct 05 2017
... and I've checked the 127.0.0.1:8071 in my browser after opening Spyder. Nothing is shown on that page, but the tab title "OS Web terminal" is displayed (better than nothing, I guess!)
@andfoy commented on Thu Oct 05 2017
@jxrossel Is there any message on the developer Web console?
@jxrossel commented on Thu Oct 05 2017
@andfoy commented on Thu Oct 05 2017
@jxrossel Can you test if pywinpty is working as expected? Please post the output of the following commands (From a Python prompt):
@jxrossel commented on Thu Oct 05 2017
process.spawn(r'C:\windows\system32\cmd.exe')--> True@andfoy commented on Thu Oct 05 2017
@jxrossel Finally an error! Let me check, it seems that this belongs to pywinpty rather than spyder-terminal. However, let me investigate more about it, this is the first instance of such issue.