You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Infinite loop in PyRun_InteractiveLoopFlags() if PyRun_InteractiveOneFlags() raises an error #52317
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:
assignee=Noneclosed_at=<Date2017-10-29.09:14:39.481>created_at=<Date2010-03-05.12:50:17.892>labels= ['interpreter-core', 'type-crash']
title='Infinite loop in PyRun_InteractiveLoopFlags() if PyRun_InteractiveOneFlags() raises an error'updated_at=<Date2017-10-29.09:14:39.479>user='https://github.com/vstinner'
PyRun_InteractiveOneFlags() documentation is also wrong: the result can only be: 0 (succes), -1 (exception raised) or E_EOF (=11, end of file).
tlesher commented on Apr 8, 2010
tleshermannequin
Mannequin
More actions
I just hit this one myself, and was about to write a bug and patch.
On reviewing the patch:
This really has the same issue as the original code: it detects one of a few known return values, and will infinitely loop on an unexpected return value. It would be better to explicitly check for 0 (continue), E_EOF (exit normally), and any other result (exit abnormally).
I don't think you want to unconditionally call PyErr_Print(), because you don't know for sure that an exception is set.
Returning 0 from PyRun_InteractiveLoopFlags() when an error occurs is a behavior change, which makes its documentation incorrect (meaning there should also be a doc patch). But to be honest, I don't think it's correct to return 0 in this case. It seems better to return the actual error code (which also requires a doc patch)
If you don't have time to update the patch, let me know and I'll put one together.
I'd prefer not exit program but try to use Py_FileSystemDefaultEncoding as enc when sys.stdin is invalid. On most cases, setting sys.stdin to some other invalid value does means the program could not continue running.
ysjray commented on Apr 2, 2011
ysjraymannequin
Mannequin
More actions
On most cases, setting sys.stdin to some other invalid value does means the program could not continue running.
Sorry, it should be:
On most cases, setting sys.stdin to some other invalid value does not mean the program could not continue running.
tlesher commented on Mar 10, 2012
tleshermannequin
Mannequin
More actions
Victor: would you object to ysj.ray's solution?
I don't think it was an option when we last looked at this issue.
tlesher commented on Mar 11, 2012
tleshermannequin
Mannequin
More actions
Updated patch: use Py_FileSystemDefaultEncoding (if possible) when sys.stdin is (or becomes) invalid; if none, then fails without entering infinite loop. Docs for PyRun_InteractiveLoopFlags have been updated.
tlesher commented on Mar 12, 2012
tleshermannequin
Mannequin
More actions
Corrected const warning in previous patch.
BreamoreBoy commented on Jun 27, 2014
BreamoreBoymannequin
Mannequin
More actions
I've failed to reproduce this using latest default on Windows 7, would someone else like to try please.
xdegaye commented on Oct 29, 2017
xdegayemannequin
Mannequin
More actions
The infinite loop may occur if one of the functions called by PyRun_InteractiveOneObject() returns persistently -1. This may be the case when there is no more memory and is handled by bpo-30696.
It is not possible anymore to reproduce the infinite loop reported in the initial post. See how the 'enc' parameter of PyParser_ASTFromFileObject() is NULL in the following gdb session:
$ gdb -q python -q
Reading symbols from python...done.
(gdb) run
Starting program: /path_to/src/python/master/python
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Python 3.7.0a2+ (heads/master:bdf4298ae2, Oct 29 2017, 09:44:50)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license"for more information.
>>> import sys
>>>
Program received signal SIGINT, Interrupt.
0x00007ffff719daa7 inselect() from /usr/lib/libc.so.6
(gdb) break PyParser_ASTFromFileObject
Breakpoint 1 at 0x5555555b38d1: file Python/pythonrun.c, line 1181.
(gdb) continue
Continuing.
sys.stdin = None
Activity
vstinner commentedon Mar 5, 2010
PyRun_InteractiveLoopFlags() only stops if PyRun_InteractiveOneFlags() returns E_EOF. But PyRun_InteractiveOneFlags() if an error occurs:
You can reproduce the error by adding the followg line to the end of Lib/site.py:
Attached patch is for py3k, but the bug does also exist in trunk.
vstinner commentedon Mar 5, 2010
PyRun_InteractiveLoop() doesn't specify the possible return value. It's maybe because it's always zero and that the error are not handled :-)
http://docs.python.org/c-api/veryhigh.html#PyRun_InteractiveLoop
PyRun_InteractiveOneFlags() documentation is also wrong: the result can only be: 0 (succes), -1 (exception raised) or E_EOF (=11, end of file).
tlesher commentedon Apr 8, 2010
I just hit this one myself, and was about to write a bug and patch.
On reviewing the patch:
This really has the same issue as the original code: it detects one of a few known return values, and will infinitely loop on an unexpected return value. It would be better to explicitly check for 0 (continue), E_EOF (exit normally), and any other result (exit abnormally).
I don't think you want to unconditionally call PyErr_Print(), because you don't know for sure that an exception is set.
Returning 0 from PyRun_InteractiveLoopFlags() when an error occurs is a behavior change, which makes its documentation incorrect (meaning there should also be a doc patch). But to be honest, I don't think it's correct to return 0 in this case. It seems better to return the actual error code (which also requires a doc patch)
If you don't have time to update the patch, let me know and I'll put one together.
vstinner commentedon Apr 11, 2010
I don't have time to write a better patch, please improve mine :-)
vstinner commentedon May 19, 2010
tlesher> If you don't have time to update the patch, let me know and I'll put one together.
I would be happy if you write a new patch :-)
vstinner commentedon Apr 2, 2011
Issue bpo-11730 has been marked as duplicate.
ysjray commentedon Apr 2, 2011
I'd prefer not exit program but try to use Py_FileSystemDefaultEncoding as enc when sys.stdin is invalid. On most cases, setting sys.stdin to some other invalid value does means the program could not continue running.
ysjray commentedon Apr 2, 2011
Sorry, it should be:
On most cases, setting sys.stdin to some other invalid value does not mean the program could not continue running.
tlesher commentedon Mar 10, 2012
Victor: would you object to ysj.ray's solution?
I don't think it was an option when we last looked at this issue.
tlesher commentedon Mar 11, 2012
Updated patch: use Py_FileSystemDefaultEncoding (if possible) when sys.stdin is (or becomes) invalid; if none, then fails without entering infinite loop. Docs for PyRun_InteractiveLoopFlags have been updated.
tlesher commentedon Mar 12, 2012
Corrected const warning in previous patch.
BreamoreBoy commentedon Jun 27, 2014
I've failed to reproduce this using latest default on Windows 7, would someone else like to try please.
xdegaye commentedon Oct 29, 2017
The infinite loop may occur if one of the functions called by PyRun_InteractiveOneObject() returns persistently -1. This may be the case when there is no more memory and is handled by bpo-30696.
It is not possible anymore to reproduce the infinite loop reported in the initial post. See how the 'enc' parameter of PyParser_ASTFromFileObject() is NULL in the following gdb session:
Breakpoint 1, PyParser_ASTFromFileObject (fp=fp@entry=0x7ffff7461860 <_IO_2_1_stdin_>, filename=filename@entry='<stdin>', enc=enc@entry=0x0, start=start@entry=256, ps1=ps1@entry=0x7ffff6e7b220 ">>> ", ps2=ps2@entry=0x7ffff6e7beb8 "... ", flags=0x7fffffffe338, errcode=0x7fffffffe244, arena=0x7ffff6eb2160) at Python/pythonrun.c:1181 1181 { (gdb) continue Continuing. >>> print(chr(0xe9)) é Breakpoint 1, PyParser_ASTFromFileObject (fp=fp@entry=0x7ffff7461860 <_IO_2_1_stdin_>, filename=filename@entry='<stdin>', enc=enc@entry=0x0, start=start@entry=256, ps1=ps1@entry=0x7ffff6e7b220 ">>> ", ps2=ps2@entry=0x7ffff6e7beb8 "... ", flags=0x7fffffffe338, errcode=0x7fffffffe244, arena=0x7ffff6eb2160) at Python/pythonrun.c:1181 1181 { (gdb) continue Continuing. >>>Closing as out of date.