New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IDLE restarts when one debugs code raising SystemExit #71136
Comments
To be more specific: if one runs a file, the shell is restarted (with the file name). In the file, raise SystemExit is normally the same as running off the end of the file, and a prompt is printed. If one runs a file with debugger on, [DEBUG ON] is printed before the prompt. However, SystemExit while debugging causes a Restart Shell before the [DEBUG ON] and >>> prompt. The 2nd restart does not normally happen when debugging finishes. It does not happen when any other exception is raised; instead a traceback is printed as normal. This is a minor bug, but it does prevent interactive examination of the process after debugging. There is special code in run.py to catch SystemExit and not print a traceback. My guess in a bug in RemoteDebugger.py that causes (allows) the execution process to exit or otherwise get detached from the IDLE process. When the IDLE process loses contact with the current execution process, it starts a new one. |
Terry, Your |
Thanks, that may make debugging this (and creating a test) easier. I have only seriously used debugger with files, and often with breakpoints in the file. |
This issue has worse consequences than I previously thought. It also affects If you run a program raising |
bpo-14111 is about handling ^C while debugging. So for now I will assume that handling 'raise KeyboardInterrupt' is part of that issue. |
The problem is cause by run.py:main function, when it catch KeyboardInterrupt or SystemExit, it won't put a blank msg back to response_queue, that cause the loop in run.py:main triggering except queue.Empty to continue the loop. So, I think the KeyboardInterrupt hang is a bug, cause by the infinity loop above, but SystemExit will raise SystemExit again, and break down the loop, let the shell restart. I think this isn't a bug. Let's say there is a code like this: x = 10
print(x)
raise SystemExit
print(x) When using IDLE to run this file without debugger, it will print 10 and leave below code. But when you type "x" in the shell, it will pop up 10, that means the shell environment didn't exit, still exist inside. But if you open the debugger, let SystemExit break the loop and restart the shell, I think this is a normal behavior -- that it should exit the shell (and restart it) |
PR 1711 fix KeyboardInterrupt with adding rpc.repsonse_queue.put, but it will not print out the exception traceback. And for SystemExit, wait for discussion result. |
Louie> If you run your example in Python with -i, you will see the same behavior, except for the traceback, as with IDLE. F:\dev\cpython>python -i -c "x=10; print(x); raise SystemExit"
Running Debug|Win32 interpreter...
10
Traceback (most recent call last):
File "<string>", line 1, in <module>
SystemExit
>>> x
10 Ditto for "python -i testfile.py". I would like the behavior to be the same when debugging. |
|
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: