IDLE: infinite print loop hangs and crashes #112938
Comments
|
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, 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 |
|
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. |
|
I can reproduce this, even on Linux (holding 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.
So, it seems that the #104027 and #104076 |
|
@zerothi Thank you for the search. Although |
pythongh-88496 replaced text.update with text.update_idletasks in two files to fix test failures on macOS. While theoretically correct, the result was Shell freezing when receiving continuous short strings to print. The guess is that there was no idle time in which to do the screen update. Reverting the change in one of the files, outwin, fixes the issue. The test will be patched as needed on macOS.
|
@zerothi Thank you for the search. Although |
…nuous output. (#124310) #88496 replaced text.update with text.update_idletasks in colorizer.py and outwin.py to fix test failures on macOS. While theoretically correct, the result was Shell freezing when receiving continuous short strings to print. Test: `while 1: 1`. The guess is that there is no idle time in which to do the screen update. Reverting the change in one of the files, outwin, fixes the issue. Colorizer runs ever 1/20 second and seems to work fine. When running test-outwin on macOS, alias 'update' to 'update_idletasks on the text used for testing.
… continuous output. (pythonGH-124310) python#88496 replaced text.update with text.update_idletasks in colorizer.py and outwin.py to fix test failures on macOS. While theoretically correct, the result was Shell freezing when receiving continuous short strings to print. Test: `while 1: 1`. The guess is that there is no idle time in which to do the screen update. Reverting the change in one of the files, outwin, fixes the issue. Colorizer runs ever 1/20 second and seems to work fine. When running test-outwin on macOS, alias 'update' to 'update_idletasks on the text used for testing. (cherry picked from commit d5f95ec) Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
… continuous output. (pythonGH-124310) python#88496 replaced text.update with text.update_idletasks in colorizer.py and outwin.py to fix test failures on macOS. While theoretically correct, the result was Shell freezing when receiving continuous short strings to print. Test: `while 1: 1`. The guess is that there is no idle time in which to do the screen update. Reverting the change in one of the files, outwin, fixes the issue. Colorizer runs ever 1/20 second and seems to work fine. When running test-outwin on macOS, alias 'update' to 'update_idletasks on the text used for testing. (cherry picked from commit d5f95ec) Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
…d continuous output. (GH-124310) (#124319) gh-112938: IDLE - Fix uninteruptable hang when Shell gets rapid continuous output. (GH-124310) #88496 replaced text.update with text.update_idletasks in colorizer.py and outwin.py to fix test failures on macOS. While theoretically correct, the result was Shell freezing when receiving continuous short strings to print. Test: `while 1: 1`. The guess is that there is no idle time in which to do the screen update. Reverting the change in one of the files, outwin, fixes the issue. Colorizer runs ever 1/20 second and seems to work fine. When running test-outwin on macOS, alias 'update' to 'update_idletasks on the text used for testing. (cherry picked from commit d5f95ec) Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
… continuous output. (python#124310) python#88496 replaced text.update with text.update_idletasks in colorizer.py and outwin.py to fix test failures on macOS. While theoretically correct, the result was Shell freezing when receiving continuous short strings to print. Test: `while 1: 1`. The guess is that there is no idle time in which to do the screen update. Reverting the change in one of the files, outwin, fixes the issue. Colorizer runs ever 1/20 second and seems to work fine. When running test-outwin on macOS, alias 'update' to 'update_idletasks on the text used for testing.
… continuous output. (python#124310) python#88496 replaced text.update with text.update_idletasks in colorizer.py and outwin.py to fix test failures on macOS. While theoretically correct, the result was Shell freezing when receiving continuous short strings to print. Test: `while 1: 1`. The guess is that there is no idle time in which to do the screen update. Reverting the change in one of the files, outwin, fixes the issue. Colorizer runs ever 1/20 second and seems to work fine. When running test-outwin on macOS, alias 'update' to 'update_idletasks on the text used for testing.
I tested the 3.12 backport on unix, and there I could successfully do Ctrl+C to escape. Thanks for this! |
…d continuous output. (GH-124310) (#124318) gh-112938: IDLE - Fix uninteruptable hang when Shell gets rapid continuous output. (GH-124310) #88496 replaced text.update with text.update_idletasks in colorizer.py and outwin.py to fix test failures on macOS. While theoretically correct, the result was Shell freezing when receiving continuous short strings to print. Test: `while 1: 1`. The guess is that there is no idle time in which to do the screen update. Reverting the change in one of the files, outwin, fixes the issue. Colorizer runs ever 1/20 second and seems to work fine. When running test-outwin on macOS, alias 'update' to 'update_idletasks on the text used for testing. (cherry picked from commit d5f95ec) Co-authored-by: Terry Jan Reedy <tjreedy@udel.edu>
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
The text was updated successfully, but these errors were encountered: