-
-
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
Can't start spyder2.2 on Win 7, crashes upon saving .spyder.ini #1242
Comments
From jed.lud...@gmail.com on 2013-01-30T22:06:39Z Thanks for the report. This should be resolved by the (most recent!) solution to issue #1086 . Revision d9438fb9d937 and revision 247a90dc6a43 are the relevant commits. The next beta release will have these incorporated. Stay tuned. Status: Duplicate |
From ruqin...@gmail.com on 2013-02-05T15:26:28Z Thanks for the response and the latest beta2! I've just gave the new version a try but unfortunately it doesn't seem to have fixed this problem ( issue #1242 ). I still need to let the interpreter sleep 0.05 seconds after it removes the old .spyder.ini file and before it writes a new one to get Spyder running with my Enthought Python 2.7.3/Win7. |
From jed.lud...@gmail.com on 2013-02-05T16:36:50Z Well, that is discouraging, indeed. Let's leave the discussion at issue #1086 alone and work this problem here. Would you be willing to perform another test for us to help provide one more piece of data about the source of this problem?
What happens? Do you still see the permissions error? Status: Accepted |
From jed.lud...@gmail.com on 2013-02-05T16:38:42Z issue #1086 has been merged into this issue. |
From jed.lud...@gmail.com on 2013-02-05T16:40:37Z Cc: -jed.lud...@gmail.com |
From ruqin...@gmail.com on 2013-02-06T10:27:14Z Just tried it as administrator, on a different Win7 machine, - got the same problem! and can be fixed the same way! There seem to be a small chance that things will go through without any fix: I ran the same command multiple times and it seemed to have worked once. |
From jed.lud...@gmail.com on 2013-02-06T19:49:18Z Thanks for trying the experiment. The fact that running as administrator does not solve the problem rules out Windows UAC as the source of the issue. I did a quick Process Monitor dump of all activity associated with spyder.ini during Spyder startup (see attached for a snippet, and ignore the BUFFER_OVERFLOW stuff [1]), and the file is opened and closed multiple times in a very short period of time. Perhaps Python as the OS are not keeping up with each other through all this? We have seen virus scanners play a role in this problem in the past. Who knows. Maybe introducing a small time delay as you suggest is a reasonable way to approach this. [1] http://blogs.technet.com/b/markrussinovich/archive/2005/05/17/buffer-overflows.aspx Attachment: Process_monitor_spyder_ini_activity.PNG |
From jed.lud...@gmail.com on 2013-02-06T20:16:40Z This issue was updated by revision dd24c2f01e50 . For anyone watching this issue, I'd appreciate testing feedback or code Status: Fixed |
From bwanama...@gmail.com on 2013-02-06T20:46:48Z Both of my windows 7 x64 machines work fine without the 50-ms nap introduced by this latest commit, although on one machine I did have the original problem from issue #1086 , which seemed to be fixed by using I wonder why this is such a difficult issue to track down. Is it possible to debug, maybe using gdb [1]? (I realize that's a swag [2]) Or perhaps WinDbg [3]? I feel like throwing patches at it every few months without discovering the root cause, or refactoring the approach may not be the best practice, but unfortunately I have no other recommnedation. Sorry. @-Ruqing Xu did you delete these lines ...
and try it with just the new lines in commit d9438fb9d937?
It seems to me that if you never delete the file, then you shouldn't have to sleep, right? Another idea might be to look at Hg and see what they are doing with mercurial.ini, why don't they have any issues? [1] http://www.gnu.org/software/gdb/ [2] http://en.wikipedia.org/wiki/Scientific_Wild-Ass_Guess [3] http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx |
From jed.lud...@gmail.com on 2013-02-06T22:00:10Z Oh, I'm certainly not satisfied with the approach I adopted here. The tough reality is that I've personally never been able to reproduce the issue. Even if I could the fact that a very subtle timing change can make it disappear means the very act of debugging would probably slow things down enough to make the problem go away :). Couple that with the fact so many different fixes have made it disappear---disabling virus scanners [1], deleting the file first ( issue #1086 ), the "with" statement ( issue #1086 again), throwing rotten fruit at your display (maybe?). It probably deserves more attention. I'm just not sure where to apply the attention today or how I would determine if my attention actually made an impact! [1] https://groups.google.com/forum/#!topic/spyderlib/upzevMIpjyY/discussion |
From ruqin...@gmail.com on 2013-02-07T08:18:59Z OK I gave a try by commenting out the two lines of file removal as well as my time delay, and yes it proceeded without any problem. |
From jed.lud...@gmail.com on 2013-02-07T13:45:58Z Lovely. So now the question is: Do we remove the time delay and risk the re-injection of a permissions bug for other users? Incidentally, I just worked through a similar permissions issue for a Python(x,y) user [1], and I can say that this def __save(self): did NOT solve the problem for him. Instead, I had to go all the way to this def __save(self):
before it solved his permissions issue. Pierre, Carlos, do you have any thoughts? [1] https://code.google.com/p/pythonxy/issues/detail?id=599 Cc: pierre.raybaut ccordoba12 |
From ruqin...@gmail.com on 2013-02-07T14:58:04Z Interestingly, the code works without the time delay on the same machine if I invoke it with the latest WinPython(x64). |
From ruqin...@gmail.com on 2013-02-07T15:27:30Z I suggest rewriting this function as the following, nothing new but the logic is more readable:
|
From bwanama...@gmail.com on 2013-02-07T16:40:56Z This disregards commit d9438fb9d937 from issue #1086 completely. Although I like the idea of catching the IOError and either handling it with the either the "delete and sleep" option or exiting gracefully perhaps with a formatted bug report message, I think that it's better to retain the method of using My suggestion would be something similar:
|
From jed.lud...@gmail.com on 2013-02-08T13:52:03Z This issue was updated by revision 546216264601 . Implemented exception handling as suggested by @ruqingxu and @-bwanamarko. Thanks |
From ccordoba12 on 2013-04-06T20:25:53Z Labels: Cat-SpyderGUI |
From jed.lud...@gmail.com on 2013-04-26T11:48:38Z issue #1141 has been merged into this issue. |
From ruqin...@gmail.com on 2013-01-30T23:49:45Z
Spyder Version: 2.2.0beta1
Python Version: 2.7.3
Qt Version: 4.7.4, PySide 1.1.0 on Windows
What steps will reproduce the problem?
================begin of screen output===========
D:\temp\spyder-2.2.0beta1>python bootstrap.py
Executing Spyder from source checkout
Revision None:None, Branch: None
Traceback (most recent call last):
File "bootstrap.py", line 73, in
from spyderlib import spyder, get_versions
File "D:\temp\spyder-2.2.0beta1\spyderlib\spyder.py", line 82, in
from spyderlib.utils.environ import WinUserEnvDialog
File "D:\temp\spyder-2.2.0beta1\spyderlib\utils\environ.py", line 17,
in
from spyderlib.widgets.dicteditor import DictEditor
File "D:\temp\spyder-2.2.0beta1\spyderlib\widgets\dicteditor.py", lin
e 31, in
from spyderlib.guiconfig import get_icon, get_font
File "D:\temp\spyder-2.2.0beta1\spyderlib\guiconfig.py", line 163, in
set_default_color_scheme(_name, replace=False)
File "D:\temp\spyder-2.2.0beta1\spyderlib\guiconfig.py", line 160, in
set_default_color_scheme
set_color_scheme(name, COLORS[name], replace=replace)
File "D:\temp\spyder-2.2.0beta1\spyderlib\guiconfig.py", line 155, in
set_color_scheme
CONF.set(section, "names", sorted(list(set(names))))
File "D:\temp\spyder-2.2.0beta1\spyderlib\userconfig.py", line 329, i
n set
self.__save()
File "D:\temp\spyder-2.2.0beta1\spyderlib\userconfig.py", line 173, i
n __save
conf_file = file(fname, 'w')
IOError: [Errno 13] Permission denied: u'C:\Users\uu.spyder2.spyder.ini'
================end of screen output===========
Please provide any additional information below
. While it complains about file writing permission, I've triple-checked and there's absolutely no problem in the folder's permission setting. Here's what I eventually found:
In source file userconfig.py,
line#
166 # See comment
#5
on issue #1086 167 if osp.isfile(fname):168 os.remove(fname)
169
170 conf_file = file(fname, 'w')
If line 170 is invoked right after line 168, which calls os.remove(), the OS, at least in my Win7 case, couldn't finish the file removal fast enough, and is still locking this file when python is trying to open it as a new file.
I added two lines after line#168 and they solved the problem immediately:
from time import sleep
sleep(0.05)
I'm not sure if it's just my computer or is it a more universal issue. Apparently the OS call by python does not wait for the OS to finish its job.
Original issue: http://code.google.com/p/spyderlib/issues/detail?id=1242
The text was updated successfully, but these errors were encountered: