Access violation writing 0x0000000000000000 on Windows 7 #59
Comments
andfoy
changed the title
|
Actually, it seems that Windows API functions should be declared explicitly: asweigart/pyperclip#25 (comment) |
|
Still doesn't work: |
|
... and another error appeared in spyder after trying to open/close a terminal: |
|
I think this is an issue related to your distribution header files, I don't know what else to do on your case. |
|
You mean it doesn't / won't work with WinPython as distribution ? |
|
@stonebig, we have a problem here, have you had more problems with Access Violation Errors? |
|
@jxrossel, I've just asked to the current mantainer of WinPython if he can give us some help. |
|
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. |
|
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. I 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? |
|
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. |
|
It seems as if the issue has resurfaced: cf jupyterlab/jupyterlab#3647 |
|
@blink1073 It seems the error is still present on some x64 Windows Python distributions. AFAIK, we cannot solve this on our own account. |
|
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? |
|
Ray, two things:
|
|
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 Regardless of that, can you (or someone with this problem) try my suggestion? edit: OK, I didn't spot this part:
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
changed the title
|
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. |
|
Alternatively, we could raise an |
|
Good idea! It's better to do it here to avoid other applications using Could you take care of that @blink1073? |
|
Yep, coming right up! |
|
Nice! Thanks a lot! |
|
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 |
|
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
|
|
@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 I tried again and got the access violation: ...and I'm now continuing to get the access violation with that code |
|
@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. |
|
@dhirschfeld After trying the high-level access, does the low-level API works for you? |
|
Yep, seems to. >>> 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 p |
|
Ah, 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 p |
|
Here 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. |
|
On Windows7 Pro 64bit, SP1: |
|
And 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) |
|
|
Calling >>> 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 >>> 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 |
|
I can't even import winpty on Windows7 with python 3.5.4. .......... |
@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.
The text was updated successfully, but these errors were encountered: