Repository navigation
IDLE: infinite print loop hangs and crashes #112938
Description
Activity
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, butdrawRect:is not.) I observe a very similar spindump after doingwhile 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
updateor at leastupdate idletasksto keep UI responsive when the thread for the Tk interpreter is busy. But usingupdatehas 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+calculationThank 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.
I can reproduce this, even on Linux (holding
^Cdoes 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-forgeprovided) - 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-forgeprovided) - Linux: 3.11.4 has this problem (
conda-forgeprovided) - Windows: 3.11.4 has this problem (
conda-forgeprovided)
So, it seems that the
updatechange 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@zerothi Thank you for the search. Although
update_idletasksmight be theoretically better, reverting toupdatein 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.Reacted by Nick Papior@zerothi Thank you for the search. Although
update_idletasksmight be theoretically better, reverting toupdatein 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 interruptingwhile 1: 1would be appreciated.- added a commit that references this issue
on Sep 22, 2024 - linked a pull request that will close this issue[3.13] gh-112938: IDLE - Fix uninteruptable hang when Shell gets rapid continuous output. (GH-124310) #124318
on Sep 22, 2024 - added a commit that references this issue
on Sep 22, 2024 @zerothi Thank you for the search. Although
update_idletasksmight be theoretically better, reverting toupdatein 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 interruptingwhile 1: 1would be appreciated.I tested the 3.12 backport on unix, and there I could successfully do Ctrl+C to escape.
I am not able to test on a windows machine... :(Thanks for this!
- added a commit that references this issue
on Sep 27, 2024
Bug report
Interactively execute
while 1: 1and Python hangs while, on Windows, a steady stream of1s 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