[issue21073] Py_ReprEnter potentially misbehaves during malformed thread states
Roundup Robot added the comment: New changeset c42cce290d50 by Antoine Pitrou in branch '3.4': Issue #21073: explain why Py_ReprEnter() allows for a missing thread state. http://hg.python.org/cpython/rev/c42cce290d50 New changeset fb217fc457ca by Antoine Pitrou in branch 'default': Issue #21073: explain why Py_ReprEnter() allows for a missing thread state. http://hg.python.org/cpython/rev/fb217fc457ca -- nosy: +python-dev ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21073 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21073] Py_ReprEnter potentially misbehaves during malformed thread states
Antoine Pitrou added the comment: Ok, I've now added a comment. -- resolution: - rejected stage: - committed/rejected status: open - closed ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21073 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21073] Py_ReprEnter potentially misbehaves during malformed thread states
Antoine Pitrou added the comment:
hg annotate shows it dates back to 4f0b7acffc7d by Guido, with the following
diff:
diff --git a/Misc/NEWS b/Misc/NEWS
--- a/Misc/NEWS
+++ b/Misc/NEWS
@@ -150,6 +150,10 @@
C API
-
+- PyThreadState_GetDict() was changed not to raise an exception or
+ issue a fatal error when no current thread state is available. This
+ makes it possible to print dictionaries when no thread is active.
+
- LONG_LONG was renamed to PY_LONG_LONG.
- Added PyObject_SelfIter() to fill the tp_iter slot for the
diff --git a/Objects/object.c b/Objects/object.c
--- a/Objects/object.c
+++ b/Objects/object.c
@@ -2119,7 +2119,7 @@
dict = PyThreadState_GetDict();
if (dict == NULL)
- return -1;
+ return 0;
list = PyDict_GetItemString(dict, KEY);
if (list == NULL) {
list = PyList_New(0);
Unless Guido has changed his mind about it, I'd close this issue as rejected ;-)
--
nosy: +gvanrossum, pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue21073
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21073] Py_ReprEnter potentially misbehaves during malformed thread states
Antoine Pitrou added the comment: (but you're right, we could add a comment explaining this) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21073 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21073] Py_ReprEnter potentially misbehaves during malformed thread states
Guido van Rossum added the comment: No, I haven't changed my mind. Feel free to add a comment explaining this. :-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21073 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue21073] Py_ReprEnter potentially misbehaves during malformed thread states
New submission from Itai Bar-Natan: While browsing the Python source code, I found this suspicious snippet in Py_ReprEnter: dict = PyThreadState_GetDict(); if (dict == NULL) return 0; It seems to me like the last line should be return -1;. The way the program currently behaves, if PyThreadState_GetDict() fails and returns NULL, Py_ReprEnter will fail silently and always report that the input isn't in a recursive loop. The correct behavior is to report an error. It would be difficult to explicitly exhibit this error since it relies on another component of Python failing first. One possible way would be to call PyObject_Repr on a recursive structure before fully initializing Python. I haven't tested this. Alternately, it's possible that this behavior is intentional because we want PyObject_Repr to work for non-self-referential structures even before Python is fully initialized (perhaps it could be called during initialization), in exchange for a small risk of failure if it is called with a self-referential structure before initialization. In that case I suggest that this should be pointed out explicitly in the comments to this function. -- components: Interpreter Core messages: 214920 nosy: itaibn priority: normal severity: normal status: open title: Py_ReprEnter potentially misbehaves during malformed thread states type: behavior versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue21073 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
