-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Spyder console crashes when trying to type in console after running script #1106
Comments
From ccordoba12 on 2012-07-03T08:44:40Z I'm also getting a failure on Linux following your procedure but I got a different traceback: Exception in thread Thread-2: In my case the problem was triggered if I don't select 'Interact with the Python interpreter after execution'. If I have it checked then I see no problem (which is the quite the opposite of your problem!). The thing is I really don't know how to debug this. Summary: Spyder console crashes when trying to type in console after running script |
From ccordoba12 on 2012-07-03T09:52:04Z I could see the last failure in Win XP too. However I was not able to reproduce your problem in Win 7 with the latest Python(x,y). You see the issue only when there is a print line at the end or for any other file you're trying to execute? I say it because this seems to me a problem with your antivirus. What happens if you deactivate it? |
From space...@gmail.com on 2012-07-13T11:22:03Z I am getting the same error in Mac OS Lion. I've just installed Spyder using MacPorts and from the first test I made it gave these errors. The big problem is that sometimes my scripts hang up and I have to restart spyder. It's quite annoying. Any idea on how to solve this? Exception in thread Thread-2: |
From ebori...@gmail.com on 2012-07-19T12:42:43Z This should be fixed in MacPorts now. Try upgrading. |
From ebori...@gmail.com on 2012-07-20T10:45:30Z Updated patch. https://trac.macports.org/browser/trunk/dports/python/py-spyder/files/spyderlib_utils_bsdsocket.py.diff?rev=95738 |
From ccordoba12 on 2012-07-22T15:31:00Z Hi eborisch, thanks a lot for the patch. I have three questions for you:
|
From ebori...@gmail.com on 2012-07-23T06:48:30Z The issue I observed was that the first recv would return without error and len(datalen) < SZ. There are many reasons this can happen (I didn't try to suss out which was occurring) on a socket -- indeed by design, without MSG_WAITALL, the size returned may be less than SZ without any error [1]. This would then fail unpacking and raise the error seen in comments 1 and 3 above. I changed both recv calls in the function to use MSG_WAITALL, and removed the (now unneeded) "while len(data) < dlen:" loop construct. Any shorter receptions should now be due to errors and handled as needed[2]. I am not at all familiar with windows sockets, but this should work on *nix (MacOS included.) From the recv manpage: |
From pierre.raybaut on 2012-07-28T06:06:34Z Thanks eborisch for taking the time to fix things and share them afterwards. However, I think that there's been a misunderstanding. There are two issues here:
def read_packet(sock, timeout=None): |
From pierre.raybaut on 2012-07-28T06:11:57Z This issue was updated by revision 4032473a38f7 . Fixes original issue as described by daan.rabijns. In other words, a dead |
From pierre.raybaut on 2012-07-28T06:12:41Z Here is the patch associated to my suggestion at the end of comment Status: Started Attachment: patch_for_bsdsocket.diff |
From mvi...@gmail.com on 2012-09-10T00:47:11Z I suggest to keep the Windows version of the patch for all platforms. MSG_WAITALL is not quite portable, but calling send() and recv() in a loop always works no matter what (it's the usual way of programming with sockets, recommended by pretty much every book out there). In Python you can avoid the loop for send() by calling sendall() instead, but sadly there's no recvall() equivalent. :( |
From ebori...@gmail.com on 2012-09-10T06:53:38Z The windows version of the patch doesn't handle the case when 'datalen = sock.recv(SZ)' is not fully sized (len(datalen) < SZ). This is the error that was occurring in comments 1 and 3, above. Please fix that before removing the !windows flavor. |
From mvi...@gmail.com on 2012-09-10T12:35:20Z Also if the socket connection is cut from the other side the receiving end would enter an infinite loop. And it's also possible to read more data than wanted in the last recv() call. A possible fix: datalen = recvall(sock, SZ) And add this auxiliary function: def recvall(sock, length): In recvall() the length of the data already read is substracted to the total length to prevent reading more bytes than wanted, and the check on new_data prevents the infinite loop if the connection is closed from the other end. There's also the problem with the struct format string but that belongs to issue #1016 so I didn't change it, but it should probably be "<L" or "!L" or something like that. One more thing, it wouldn't hurt to have a maximum size limit, so in case of an error we don't end up trying to read 4Gb of data from the socket. Yeah, socket programming sucks ;) |
From mvi...@gmail.com on 2012-09-10T13:17:10Z Sorry, that was issue #1146 I meant back there. |
From mvi...@gmail.com on 2012-09-10T13:21:28Z As clarified in issue #1146 the struct pack format string was not the issue here. It may be worth considering using "<L" instead just to simplify the code when checking for a maximum size limit (otherwise there'd have to be a minimum size limit too, to prevent negative numbers). |
From ebori...@gmail.com on 2012-09-10T21:04:47Z And this is where MSG_WAITALL works so nicely... (on systems where it is supported.) It basically does what you are doing with your helper function, but without needing the helper function. Is there some portability concern beyond Windows for the MSG_WAITALL version? It's just cleaner if it is available, IMHO. It's likely faster, too. As we're communicating all on the same machine here, the "l" just needs to match what is used on the sending side in spyder (which I'm guessing is the write_packet() def directly above read_packet()) ... it's using struct.pack("l"), too. |
From ebori...@gmail.com on 2012-09-10T21:05:55Z "As we're communicating all on the same machine here" << Someone more involved with the project please speak up if I am incorrect here!! |
From pierre.raybaut on 2012-09-13T11:42:55Z "Is there some portability concern beyond Windows for the MSG_WAITALL version?" >> Yes, unfortunately, as MSG_WAITALL simply does not exist on Windows platforms. "As we're communicating all on the same machine here" >> that's correct! |
From ebori...@gmail.com on 2012-09-13T17:24:10Z My question was if for modern UNIX systems there was any portability concern. |
From ccordoba12 on 2012-09-19T07:37:51Z issue #1149 has been merged into this issue. |
From pierre.raybaut on 2012-09-23T05:14:53Z This issue was closed by revision ad0b96cff9a3 . Status: Fixed |
From ccordoba12 on 2013-02-04T14:40:34Z issue #1162 has been merged into this issue. |
From ebori...@gmail.com on 2013-02-06T07:35:46Z I'm not sure this is fixed for windows: (but perhaps it is working for most people anyway?) Windows implementationdatalen = sock.recv(SZ) # len(datalen) >= 0 w/o raising exceptions; not guaranteed to be == SZ I think perhaps the best thing is to use a recvall function like suggested in comment if os.name == "nt": def read_packet(sock, timeout=None): |
From pierre.raybaut on 2013-02-10T05:47:46Z Why not? Have you tested this on both Windows and Linux? We could add this change in v2.2 but if we do, it has to be now, for beta3 for example. |
From jtaylor....@googlemail.com on 2013-03-15T15:19:46Z the sending in bsdsocket.py in this does not handle partial sends, this should be fixed too. def temp_fail_retry(error, fun, _args): |
From jtaylor....@googlemail.com on 2013-03-15T15:31:34Z heres a patch: +def temp_fail_retry(error, fun, *args):
@@ -26,7 +36,10 @@
|
From pierre.raybaut on 2013-03-17T07:27:30Z This issue was updated by revision 6c978bee1d85 . Please test this change and mark this issue as Verified once it's done. |
From ccordoba12 on 2013-03-17T07:37:28Z Labels: -MS-v2.1 MS-v2.2 |
From jtaylor....@googlemail.com on 2013-04-08T14:13:50Z works fine on ubuntu 13.04 |
From ccordoba12 on 2013-04-08T14:22:53Z Thanks Julian for checking it. Status: Verified |
From ccordoba12 on 2013-07-04T10:32:50Z issue #1474 has been merged into this issue. |
From ccordoba12 on 2014-08-23T12:55:21Z issue #113 has been merged into this issue. |
From ccordoba12 on 2015-01-02T18:26:25Z issue #1146 has been merged into this issue. |
From ccordoba12 on 2015-01-02T18:33:19Z issue #1173 has been merged into this issue. |
From daan.rab...@gmail.com on 2012-07-01T09:53:07Z
Spyder Version: 2.1.9
Python Version: 2.7.2
Qt Version: 4.7.4, PyQt4 (API v1) 4.8.6 on Windows Vista
What steps will reproduce the problem?
Instead, I see:
Traceback (most recent call last):
File "C:\Python27\lib\site-packages\spyderlib\widgets\externalshell\pythonshell.py", line 536, in send_to_process
"toggle_inputhook_flag(True)")
File "C:\Python27\lib\site-packages\spyderlib\utils\bsdsocket.py", line 64, in communicate
write_packet(sock, command)
File "C:\Python27\lib\site-packages\spyderlib\utils\bsdsocket.py", line 24, in write_packet
sock.send(struct.pack("l", len(sent_data)) + sent_data)
socket.error: [Errno 10054] An existing connection was forcibly closed by the remote host
Please provide any additional information below
. - see screenshot
Attachment: error.png
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=1106
The text was updated successfully, but these errors were encountered: