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.

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

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.

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

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...

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 #15348, and another case I was using (start, enable debugger, open module, run module, quit).

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

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

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 #24455, which includes the changes in fix-nested-mainloop.patch for this bug).

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

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.

fix-nested-mainloop.patch was superceded by fix-nested2.patch for #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.