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
IDLE crashes when using keyboard shortcuts to open a file. #53146
Comments
This only seems to be a problem under Windows. The error is (I'm typing it by hand):
Exception in Tkinter callback
Traceback (most recent call last):
File "E:\py30\App\lib\tkinter\__init__.py", line 1399, in __call__
return self.func(*args)
File "E:\py30\App\lib\idlelib\MultiCall.py", line 174, in handler
doafterhandler.pop()()
File "E:\py30\App\lib\idlelib\MultiCall.py", line 221, in <lambda>
doit = lambda: self.bindedfuncs[triplet[2]][triplet[0]].remove(func)
ValueError: list.remove(x): x not in list I can work around this with a batch file that uses python.exe, not I also tested IDLE under a normal python installation and the same thing happens, so, sorry, it is not a PP thing. There must be a bug in IDLE under py 3.0. I'll file this with python.org. |
I can consistently reproduce this with Python 3.0.1 by setting IDLE to start in editing mode and using Ctrl+o to open the Open dialog. Doesn't happen when using the menu item in the File menu. This leads me to believe it has something to do with keypress event processing. Also, the event for which the unbind call is failing is <Control-KeyPress-slash>. Continuing to investigate. |
Putting print statements in that part of the world shows that the reason why the list.remove fails is that while a ColorDelegator.toggle_colorize_event object is in the list, it has a different memory address than the ColorDelegator.toggle_colorize_event object to be removed. I've seen this NOT fail occasionally (the memory addresses were the same, so the list.remove succeeded), all of which would seem to imply that something has moved in memory. I'll mention that when the failure occurs, the list always has just one object, a ColorDelegator.toggle_colorize_event object. |
Attached is a patch to fix the bug. When selecting "Open" from the File Menu, "ishanderrunning" is empty. Unbind/Bind requests are handled synchronously. When pressing "Ctrl+O", "ishandlerrunning" is no longer empty, and the actual bind/unbind events get appended to "doafterhandle". The original code was running these bind/unbind events in REVERSE order by using "pop", so unbind requests were being made (and causing the error) before the proper bind request. |
Brett C. just today pushed I don't know if this patch will have any affect on this issue, but implicit relative imports are (were;-) a possible cause of intermittent problems. |
Implicit relative imports are not related to this issue. Can someone please review the given patch? |
With 3.2.3, after selecting open edit on startup and using ^O to select a file, I got a silent close of the editor window. Opening from the file menu worked. After the change of adding '0', ^O worked also. However, without a test suite, I am a little nervous about the change, as the original code might be intentional. From the module doc string: "The order by which events are called is defined by these rules:
Is popping from the end the implementation of rule 2? Code note 1: doafterhandler = self.doafterhandler (initially [] by default), so changes to the list must be mutations to affect the self attribute. while doafterhandler:
doafterhandler.pop(0)()
# is O(n*2)
doafterhandler.reverse()
while doafterhandler:
doafterhandler.pop()()
# is O(n)
for f in doafterhandler:
f()
doafterhandler[:] = []
# doafterhandler.clear() works in 3.3
# is also O(n) and replaces repeated .pop with one clear If calling first to last is proper, I prefer this last unless the callback functions somehow require that they be removed from doafterhandler before being called. Code note 2: unless the default args for handler def __create_handler(self, lists, mc_type, mc_state):
def handler(event, lists = lists,
mc_type = mc_type, mc_state = mc_state,
ishandlerrunning = self.ishandlerrunning,
doafterhandler = self.doafterhandler): are ever replaced with other arguments in handler(event) calls, their presence in the signature would appear to be holdovers from before closures. If so, the above could be simplified to I also wonder whether the double underscore and consequent name mangling for __create_handler is needed. My understanding is that this is only needed, perhaps, for multiple inheritance mixin classes, and I do not see that class _ComplexBinder qualifies. |
Thanks for your review, Terry. Popping from the end is not an implementation of rule 2. Calling event handlers is separate concept from binding/unbinding event handlers. The "doafterhandler" list contains bind/unbind requests that were made while calling event handlers. The doafterhandler "queue" should be FIFO, not LIFO. Code note 1: The running time of the algorithm is an important consideration. Your last suggestion for using a for-loop looks most appropriate, as you've said. Attached is a revised patch for it. Code note 2: The _ComplexBinder class may need refactoring, but that's a separate issue. I'm willing to review patches for that. |
I am seeing this as well. It does not repro 100% of the time, but frequently enough that its hard to get anything done. My repro is a little simpler and might help understanding the fix. Win7 I start IDLE normally from the shortcut in the install. As mentioned, using the menu to open the file seems to work more reliably. I've not had a crash that way. |
For what it's worth (maybe not much?), the version of IDLE produced by Bruce Sherwood On Mon, Feb 4, 2013 at 8:53 PM, Patrick <report@bugs.python.org> wrote:
|
New changeset 37352a3ccd54 by Roger Serwy in branch '2.7': New changeset 61092bbd1464 by Roger Serwy in branch '3.3': New changeset 6ad256175971 by Roger Serwy in branch 'default': |
I am closing this issue as being fixed. |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: