Skip to content

IDLE crashes when using keyboard shortcuts to open a file. #53146

Closed

Description

@mhuster
mannequin
BPO 8900
Nosy @terryjreedy, @taleinat, @serwy, @asvetlov
Files
  • issue8900.patch
  • issue8900_rev1.patch
  • 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:

    assignee = 'https://github.com/serwy'
    closed_at = <Date 2013-03-31.21:25:07.055>
    created_at = <Date 2010-06-04.23:58:16.759>
    labels = ['expert-IDLE', 'type-bug']
    title = 'IDLE crashes when using keyboard shortcuts to open a file.'
    updated_at = <Date 2013-03-31.21:25:07.054>
    user = 'https://bugs.python.org/mhuster'

    bugs.python.org fields:

    activity = <Date 2013-03-31.21:25:07.054>
    actor = 'roger.serwy'
    assignee = 'roger.serwy'
    closed = True
    closed_date = <Date 2013-03-31.21:25:07.055>
    closer = 'roger.serwy'
    components = ['IDLE']
    creation = <Date 2010-06-04.23:58:16.759>
    creator = 'mhuster'
    dependencies = []
    files = ['23915', '25228']
    hgrepos = []
    issue_num = 8900
    keywords = ['patch']
    message_count = 13.0
    messages = ['107113', '107128', '118698', '149228', '158311', '158348', '158363', '158369', '181416', '181419', '185651', '185675', '185677']
    nosy_count = 8.0
    nosy_names = ['terry.reedy', 'taleinat', 'roger.serwy', 'asvetlov', 'mhuster', 'Bruce.Sherwood', 'python-dev', 'Patrick.Walters']
    pr_nums = []
    priority = 'normal'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = 'behavior'
    url = 'https://bugs.python.org/issue8900'
    versions = ['Python 2.7', 'Python 3.3', 'Python 3.4']

    Activity

    1. mhuster commented on Jun 4, 2010

      mhustermannequin
      MannequinAuthor

      This only seems to be a problem under Windows.
      From a Portable Python discussion:
      I am using Portable Python 1.1, python 3.0.1.
      I am trying to set up a .bat file file to easily start IDLE. But IDLE
      is throwing an error and failing some of the time.
      It only happens if IDLE is set up to start in the edit mode. (Which I
      prefer.) And then it only throws the error the first time a file is
      opened. It doesn't seem to matter what kind of file is opened. The
      other symptom is that a new line is inserted at the top of the file
      that is opened.

      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
      pythonw.exe, but it leaves an annoying command shell window open.

      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.

    2. added
      type-crashA hard crash of the interpreter, possibly with a core dump
      on Jun 4, 2010
    3. taleinat commented on Jun 5, 2010

      @taleinat
      Contributor

      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.

    4. BruceSherwood commented on Oct 14, 2010

      BruceSherwoodmannequin
      Mannequin

      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.

    5. serwy commented on Dec 11, 2011

      serwymannequin
      Mannequin

      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.

    6. added
      type-bugAn unexpected behavior, bug, or error
      and removed
      type-crashA hard crash of the interpreter, possibly with a core dump
      on Apr 14, 2012
    7. terryjreedy commented on Apr 15, 2012

      @terryjreedy
      Member

      Brett C. just today pushed
      http://hg.python.org/cpython/rev/556b9bafdee8
      changeset: 76310:556b9bafdee8
      user: Brett Cannon <brett@python.org>
      date: Sat Apr 14 20:44:23 2012 -0400
      summary:
      IDLE was relying on implicit relative imports which have gone away in
      Python 3.3 thanks to importlib finishing the work in PEP-328 that
      accidently got carried forward.

      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.

    8. serwy commented on Apr 15, 2012

      serwymannequin
      Mannequin

      Implicit relative imports are not related to this issue.

      Can someone please review the given patch?

    9. terryjreedy commented on Apr 15, 2012

      @terryjreedy
      Member

      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:

      1. A more-specific event will be called before a less-specific event.
      2. A recently-binded event will be called before a previously-binded event, unless this conflicts with the first rule."

      Is popping from the end the implementation of rule 2?
      Is it possible that one event pair is being appended in the wrong order?
      I need to read more of the comments and code to understand this subsystem.

      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
      def handler(event)
      and 'self.' added in the body where needed.

      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.

    10. serwy commented on Apr 15, 2012

      serwymannequin
      Mannequin

      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.

    11. PatrickWalters commented on Feb 5, 2013

      PatrickWaltersmannequin
      Mannequin

      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
      Python 3.3

      I start IDLE normally from the shortcut in the install.
      Ctrl-N to open and edit window.
      Ctrl-O to open a file.
      Select file and then Idle exits.

      As mentioned, using the menu to open the file seems to work more reliably. I've not had a crash that way.

    12. BruceSherwood commented on Feb 5, 2013

      BruceSherwoodmannequin
      Mannequin

      For what it's worth (maybe not much?), the version of IDLE produced by
      Guilherme Polo in the 2009 Google Summer of Code, which VPython (vpython.org)
      uses under the name VIDLE, does not have any problem with starting with an
      edit window and in fact I always use it that way.

      Bruce Sherwood

      On Mon, Feb 4, 2013 at 8:53 PM, Patrick <report@bugs.python.org> wrote:

      Patrick added the comment:

      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
      Python 3.3

      I start IDLE normally from the shortcut in the install.
      Ctrl-N to open and edit window.
      Ctrl-O to open a file.
      Select file and then Idle exits.

      As mentioned, using the menu to open the file seems to work more reliably.
      I've not had a crash that way.

      ----------
      nosy: +Patrick.Walters


      Python tracker <report@bugs.python.org>
      <http://bugs.python.org/issue8900\>


    13. serwy commented on Mar 31, 2013

      serwymannequin
      Mannequin

      I changed the title to better reflect the original bug report.

      @bruce: I did review Guilherme's patch a while ago in bpo-10079. The editor window bug can be found in bpo-6698. These are on my todo-list, especially now that PEP-434 has been accepted.

    14. changed the title [-]IDLE crashes if Preference set to At Startup -> Open Edit Window[/-] [+]IDLE crashes when using keyboard shortcuts to open a file.[/+] on Mar 31, 2013
    15. self-assigned this
      on Mar 31, 2013
    16. python-dev commented on Mar 31, 2013

      python-devmannequin
      Mannequin

      New changeset 37352a3ccd54 by Roger Serwy in branch '2.7':
      bpo-8900: Using keyboard shortcuts in IDLE to open a file no longer raises an exception.
      http://hg.python.org/cpython/rev/37352a3ccd54

      New changeset 61092bbd1464 by Roger Serwy in branch '3.3':
      bpo-8900: Using keyboard shortcuts in IDLE to open a file no longer raises an exception.
      http://hg.python.org/cpython/rev/61092bbd1464

      New changeset 6ad256175971 by Roger Serwy in branch 'default':
      bpo-8900: merge with 3.3.
      http://hg.python.org/cpython/rev/6ad256175971

    17. serwy commented on Mar 31, 2013

      serwymannequin
      Mannequin

      I am closing this issue as being fixed.

    18. transferred this issue fromon Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

    Metadata

    Metadata

    Assignees

    Labels

    topic-IDLEtype-bugAn unexpected behavior, bug, or error

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions