The IDLE shell does not respond to commands if the debugger window is closed by clicking "X". This is due to PyShell's "executing" flag not being reset.

Steps to reproduce:

1) Start IDLE with a shell.
2) Enable debugger.
3) Press enter in the shell. (activates the debugger)
4) Close the debugger by clicking "X".

The shell is no longer responsive to new commands. Selecting "Restart Shell" does not fix the problem either.

Attached is a patch against 3.4 to solve the issue.

The debugger was originally written for running IDLE without a subprocess. As a result, calls to idb.run() from Debugger.py would block until completed.  If .interacting == 1 then clicking "X" would not close the debugger window. Once the debugger finishes, the .interacting flag would reset to 0, which then allows for the Debugger.close() method to destroy the debugger window. Clicking "Quit" is one way to have the debugger finish.

When running *with* a subprocess, the idb.run() returns immediately, since it is using the IdbProxy object instead. As a consequence, the .interacting flag is also reset to 0 immediately despite the debugger still being active. Thus, clicking "X" would allow the debugger to close without properly stopping the debugger via clicking "Quit".

A useful side-effect of the interactive debugger being active is that the PyShell.executing flag is set to true. When the debugger stops, the call to PyShell.endexecuting() from poll_subprocess() resets the .executing flag. The patch checks if PyShell's executing is true in order to prevent the Debugger Window from being closed by clicking "X". This makes the behavior is consistent with running the IDLE debugger without a subprocess.


When running IDLE without a subprocess is fully removed (see issue16123), then maintaining the Debugger code will become simpler. Until then, testing against both code paths is necessary.

While trying to address #15347, I discovered one too many corner cases where the debugger breaks IDLE. The stable_idle_debugger.diff against 3.4 contains necessary changes to make IDLE more reliable while debugging. Since the IDLE debugger is not documented these changes should not be controversial.

Here are all the cases the patch fixes:
1) Closing the debugger while debugging causes the shell to not respond to new commands when using a subprocess.
2) Pressing F5 in an editor several times with an active debugger causes IDLE to become unresponsive. 
2.1) When not using the subprocess, the patch fixes an AttributeError in runcode in PyShell.py, since .interp is not an attribute of the interpreter.
3) Closing the shell window while the debugger is debugging prevents IDLE from terminating if no editors are open. #15347
4) Closing the shell with an idle debugger causes a traceback in the shell (with no subprocess).

The patch creates the following behavior:

1) The debugger cannot be closed by clicking "X" while it is debugging. Instead, the "Quit" button gets flashed as a reminder to stop the debugger before closing.
2) Pressing F5 in the editor window while the debugger is debugging brings focus to the debugger window.
3) Closing the shell will close the debugger properly. The .close() method of Debugger.py quits the nested eventloop in .interaction() if needed.

I tested these issues and solutions on Linux. Can someone review the patch for Windows and Mac?

Is it possible to make the X button quit the debugger if enabled?

Clicking "X" while the debugger is enabled, but not actively debugging a program, will close the debugger window.

What's the intended behavior? stop debugging and quit the program? stop debugging and continue freerunning? I'm using 3.3, can you make the patch stop debugging the active running program when you click the X?

If the debugger is active, then clicking "X" will flash the "Quit" button. You must click the quit button first before closing the debugger window.

Then frigging change it!

Closing the active debugger with "X" creates a problem with references and callbacks. I encountered too many corner cases where I could not implement that behavior simply.

But of course, you are more than welcomed to try to submit a patch yourself. Just make sure that those corner cases I described earlier are handled reasonable when running IDLE with and without a subprocess.

I have never used the debugger, but I verified the bug. While something was 'hung', the debugger would not restart because something was 'busy'. I also verified that clicking [quit] first and then [x] works. I will try to test the second patch sometime.

Jimbo, the first priority is to fix crashes and hangs. We control the response to buttons we add, but the [x] close button involves the gui and operating system. So working with it can be trickier than it seems it ought to be.