IDLE: infinite print loop hangs and crashes

[terryjreedy]

Bug report

Interactively execute while 1: 1 and Python hangs while, on Windows, a steady stream of 1s is printed. In REPL, ^C stops execution with KeyboardInterrupt. In IDLE, ^C has no effect. Same for ^F6, which (at least on Windows) should kill and restart the execution process. On Windows, clicking top menu Shell, in an attempt to access Restart Shell on the dropdown menu, or clicking anywhere else, crashed IDLE and '(Not responding)' is added to the title bar. The Close button is also disabled. This Discourse post shows the eventual crash result.

I suspect that the prints come so fast that the tk event loop is somehow 'jammed'. This might be unfixable, but it might be worth a look. Can prints get lower priority? Behavior is the same in -n (no subprocess) mode, so not because of IPC socket comms. If no fix, this difference from REPL should be documented.

On macOS, the REPL behavior in Terminal is the same. In IDLE, nothing is printed. Instead, I get an immediate twirling colors ball. The only way to quit was to click the dock icon and select Force Quit.

It is possible that this should be a tkinter bug. @chrstphrchvz Any comment from your tk knowledge?

Linked PRs

• gh-112938: IDLE - Fix uninteruptable hang when Shell gets rapid continuous output. #124310
• [3.13] gh-112938: IDLE - Fix uninteruptable hang when Shell gets rapid continuous output. (GH-124310) #124318
• [3.12] gh-112938: IDLE - Fix uninteruptable hang when Shell gets rapid continuous output. (GH-124310) #124319

[chrstphrchvz]

Looking at a spindump (“Sample” in Activity Monitor) for IDLE on Tk Aqua, I see Tk prepare to redraw widgets, but it never reaches the point where it can process AppKit events (causing the spinning wait cursor/“not responding” in Force Quit) and to actually draw to the screen. (More specifically, setNeedsDisplay: is called, but drawRect: is not.) I observe a very similar spindump after doing while 1 {puts 1} in Wish console, so I do not think this behavior is specific to Tkinter. Because of widget redrawing peculiarities in Tk Aqua, thos may not match the behavior seen on X11 or Win32, and even if a workaround for this was found, I would not expect it to keep working in future Tk Aqua.

Maybe this issue arguably reflects improper design in IDLE and Wish console, but I am not familiar with the “proper” approach. For a long time, Tk documentation has said that a Tk program should to call update or at least update idletasks to keep UI responsive when the thread for the Tk interpreter is busy. But using update has also been discouraged for a long time, because it does not guarantee it will return right away rather than get stuck doing something else.
https://wiki.tcl-lang.org/page/Update+considered+harmful
https://wiki.tcl-lang.org/page/Keep+a+GUI+alive+during+a+long+calculation

[terryjreedy]

Thank you for the report. I intend to investigate the IDLE Windows behavior more. How many prints per second in Shell? Does IDLE see the ^C keypress? Possible areas for improvement are socket writing, socket reading, and ^C handling. For the socket, perhaps small pauses can be inserted. For ^C, there are also non-printing loops (or hangs?) that also cannot be interrupted. If Shell receives ^C, sends it to the execution process, and does not soon get KeyboardInterrupt, perhaps Shell could offer to kill and restart the execution process.

[zerothi]

I can reproduce this, even on Linux (holding ^C does not work either).

While I can see that this is low priority, the idle editor is great for newcomers to the language, and there inf. loops are more frequent.

• Linux: 3.11.7 has this problem. (manually compiled)
• Linux: 3.11.3 does not have this problem (conda-forge provided)
• Windows: 3.11.3 does not have this problem, although the printing of the 1's is rather slow, probably leaving some time to respond. (conda-forge provided)
• Linux: 3.11.4 has this problem (conda-forge provided)
• Windows: 3.11.4 has this problem (conda-forge provided)

So, it seems that the update change in 3.11.4 has caused this?

#104027 and #104076
?
Those two PR's are found through: https://docs.python.org/release/3.11.4/whatsnew/changelog.html#idle

[terryjreedy]

@zerothi Thank you for the search. Although update_idletasks might be theoretically better, reverting to update in idlelib.outwin fixes the hang on both Windows and macOS Catalina. It also reintroduces failure in test_outwin on Mac. I will include in my PR a narrowly targeted fix for that.

[terryjreedy]

@zerothi Thank you for the search. Although update_idletasks might be theoretically better, reverting to update in idlelib.outwin fixes the hang on both Windows and macOS Catalina. It also reintroduces failure in test_outwin on Mac. My PR includes a narrowly targeted alternate fix in test_outwin. Live testing of the patch of interrupting while 1: 1 would be appreciated.