Skip to content
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.

Sign up for GitHub

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

Jump to bottom

IDLE - remove debugger 'interacting' #59552

Open
serwy mannequin opened this issue Jul 13, 2012 · 11 comments
Open

IDLE - remove debugger 'interacting' #59552

serwy mannequin opened this issue Jul 13, 2012 · 11 comments
Assignees
@terryjreedy
Labels
3.9 only security fixes topic-IDLE type-bug An unexpected behavior, bug, or error

Comments

@serwy
Copy link
Mannequin

serwy mannequin commented Jul 13, 2012

BPO 15347
Nosy @terryjreedy, @roseman
Files
  • fix-nested-mainloop.patch
  • remove-interacting-debugger.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/terryjreedy'
closed_at = None
created_at = <Date 2012-07-13.19:32:43.023>
labels = ['expert-IDLE', 'type-bug', '3.9']
title = "IDLE - remove debugger 'interacting'"
updated_at = <Date 2019-09-19.17:23:29.086>
user = 'https://github.com/serwy'

    bugs.python.org fields:

    activity = <Date 2019-09-19.17:23:29.086>
actor = 'terry.reedy'
assignee = 'terry.reedy'
closed = False
closed_date = None
closer = None
components = ['IDLE']
creation = <Date 2012-07-13.19:32:43.023>
creator = 'roger.serwy'
dependencies = []
files = ['40550', '40581']
hgrepos = []
issue_num = 15347
keywords = ['patch']
message_count = 11.0
messages = ['165410', '221948', '228252', '228275', '250342', '251359', '251401', '251613', '255034', '255037', '352808']
nosy_count = 2.0
nosy_names = ['terry.reedy', 'markroseman']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'commit review'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue15347'
versions = ['Python 3.9']
    @serwy
    Copy link
    Mannequin Author

    serwy mannequin commented Jul 13, 2012

    IDLE fails to close if the debugger was active.

    Steps to reproduce:

    1. Start IDLE with only a shell.
    2. Enable debugger.
    3. Press enter in the shell. (Causes debugger to activate)
    4. Close the shell window. (File->Exit or click X)
    5. Click "OK" in the dialog box.

    IDLE keeps running despite all windows being closed.

    @serwy serwy mannequin added topic-IDLE type-bug An unexpected behavior, bug, or error labels Jul 13, 2012
    @BreamoreBoy
    Copy link
    Mannequin

    BreamoreBoy mannequin commented Jun 30, 2014

    A pythonw.exe process is left running if I try this with 3.4.1 on Windows 7.

    @terryjreedy
    Copy link
    Member

    A few years ago there was an issue where starting a new user process left the old user process continuing as a zombie. This time, it seems to be the idle process that becomes the zombie. I determined this by starting Idle in edit-only mode, noting the memory size of the one process, running the shell, which starting a smaller user process, closing the editor, and continuing with the reproduce steps. The larger Idle process remained. However, 'Idle' is gome from the Task Manager Application tab.

    Saimadhav (or Mark) can you run the experiment on Linux and /or Mac and report a bit more?

    The box says "The program is still running. Do you want to kill it." I am pretty sure 'the program' refers to the user process, not the Idle process. (The message should be clearer about this.)

    The message box is called in PyShell.PyShell.close (986 in 3.4.1).  If not 'Cancel', the call sequence is EditorWindow.EditorWindow.close, PyShell._close, Editor._close. PyShell._close first calls self.close_debugger.  That ends with 'Debug Off' and a new '>>> '.  I see these printed before Shell disappears.

    If step 3 is omitted, there is no problem. If I add 3b) Close the debugger, there is still a problem. So 'activating' the debugger does something that is not undone by closing the debugger and that obstructs closing.

    @terryjreedy
    Copy link
    Member

    bpo-21339, closed as a duplicate of this, has a traceback might be helpful.

    @roseman
    Copy link
    Mannequin

    roseman mannequin commented Sep 9, 2015

    Debugger.py has a nested call to mainloop() ... which is almost always a bad idea. I'm betting the close is being handled in this mainloop, and there are no more events being generated, meaning the real mainloop towards the bottom of PyShell (which checks if we've got open windows) is never being reentered.

    Will try to look at this closer, but in case anyone has a chance in the interim...

    @roseman
    Copy link
    Mannequin

    roseman mannequin commented Sep 22, 2015

    Figured out the cause of this hang, it was to do with the nested event loops.

    It turns out that mainloop() really should just be for the mainloop. Or at least quit() should only be used to quit the outer loop, as it relies on setting a static variable, so is not reentrant, i.e. does not handle nested event loops.

    I changed the nested loop to use a different mechanism to start the nested event loop (vwait, which waits for a tcl variable to be set) and terminate the nested loop (setting that variable). Have attached fix-nested-mainloop.patch.

    Fixes the problem here, and in bpo-15348, and another case I was using (start, enable debugger, open module, run module, quit).

    The one in bpo-24455 is something different, I'll look into it.

    @roseman
    Copy link
    Mannequin

    roseman mannequin commented Sep 23, 2015

    See bpo-24455 for a patch that includes the changes from this one as well as some additional changes that fixes that bug.

    @roseman
    Copy link
    Mannequin

    roseman mannequin commented Sep 25, 2015

    Doing some testing using "-n". Various close/quit scenarios are either disallowed or broken as it turns out. I found that removing the "interacting" check on close improved the matter quite substantially, so that I could quit when the debugger was sitting waiting for input, without hangs etc.

    Have attached remove-interacting-debugger.patch (which can be applied on top of fix-mainloop2.patch (from bpo-24455, which includes the changes in fix-nested-mainloop.patch for this bug).

    @terryjreedy
    Copy link
    Member

    See bpo-15348 for result of fix-mainloop2.patch on Windows.

    @terryjreedy
    Copy link
    Member

    Git patch does not apply because header does not have full paths.

    diff --git a/Debugger.py b/Debugger.py
    index e2014d1..9efe6fa 100644
    --- a/Debugger.py
    +++ b/Debugger.py

    versus

    diff -r ed694938c61a Lib/idlelib/Debugger.py
    --- a/Lib/idlelib/Debugger.py Tue Sep 22 13:08:42 2015 +0300
    +++ b/Lib/idlelib/Debugger.py Tue Sep 22 20:36:09 2015 -0700

    This is also why no *review* link after the *edit* link on right.
    I will go ahead and manually edit the file.

    @terryjreedy terryjreedy self-assigned this Nov 21, 2015
    @terryjreedy
    Copy link
    Member

    fix-nested-mainloop.patch was superceded by fix-nested2.patch for bpo-24455.
    I verified that the initial test now passes. When I click 'yes' in that box popped up by step 4, both Shell and debugger windows disappear and IDLE exists.

    The only question left is whether to apply remove-interacting-debugger.patch, which was aimed at the deprecated but not removed -n mode.

    @terryjreedy terryjreedy added the 3.9 only security fixes label Sep 19, 2019
    @terryjreedy terryjreedy changed the title IDLE - does not close if the debugger was active IDLE - remove debugger 'interacting' Sep 19, 2019
    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Assignees

    @terryjreedy terryjreedy

    Labels
    3.9 only security fixes topic-IDLE type-bug An unexpected behavior, bug, or error
    Projects
    IDLE Issues
    Status: No status
    Milestone
    No milestone
    Development

    No branches or pull requests
    1 participant
    @terryjreedy