-
-
Notifications
You must be signed in to change notification settings - Fork 32.2k
gh-126105: Fix crash in ast
module, when ._fields
is deleted
#126115
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering why we have:
if (PyObject_GetOptionalAttr((PyObject*)Py_TYPE(self), state->_fields, &fields) < 0) {
This could be because some AST nodes do not have a _fields
attribute but then, why don't we simply change it to an eager PyObject_GetAttr
?
Misc/NEWS.d/next/Library/2024-10-29-11-45-44.gh-issue-126105.cOL-R6.rst
Outdated
Show resolved
Hide resolved
32f5eed
to
980aa20
Compare
Docs give me more confidence: https://docs.python.org/3/library/ast.html#ast.AST._fields
|
I don't think that |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks!
@@ -884,19 +884,17 @@ def visitModule(self, mod): | |||
Py_ssize_t i, numfields = 0; | |||
int res = -1; | |||
PyObject *key, *value, *fields, *attributes = NULL, *remaining_fields = NULL; | |||
if (PyObject_GetOptionalAttr((PyObject*)Py_TYPE(self), state->_fields, &fields) < 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A simpler fix would have been this, right?
if (PyObject_GetOptionalAttr((PyObject*)Py_TYPE(self), state->_fields, &fields) <= 0) {
However, your fix is better.
pythonGH-126115) Previously, if the `ast.AST._fields` attribute was deleted, attempts to create a new `as`t node would crash due to the assumption that `_fields` always had a non-NULL value. Now it has been fixed by adding an extra check to ensure that `_fields` does not have a NULL value (this can happen when you manually remove `_fields` attribute). (cherry picked from commit b2eaa75) Co-authored-by: sobolevn <[email protected]>
Sorry, @sobolevn and @Eclips4, I could not cleanly backport this to
|
GH-126130 is a backport of this pull request to the 3.13 branch. |
I'll take care of backport to 3.12. |
… deleted (pythonGH-126115) Previously, if the `ast.AST._fields` attribute was deleted, attempts to create a new `as`t node would crash due to the assumption that `_fields` always had a non-NULL value. Now it has been fixed by adding an extra check to ensure that `_fields` does not have a NULL value (this can happen when you manually remove `_fields` attribute). (cherry picked from commit b2eaa75) Co-authored-by: sobolevn <[email protected]>
GH-126132 is a backport of this pull request to the 3.12 branch. |
…ed (GH-126115) (#126130) gh-126105: Fix crash in `ast` module, when `._fields` is deleted (GH-126115) Previously, if the `ast.AST._fields` attribute was deleted, attempts to create a new `as`t node would crash due to the assumption that `_fields` always had a non-NULL value. Now it has been fixed by adding an extra check to ensure that `_fields` does not have a NULL value (this can happen when you manually remove `_fields` attribute). (cherry picked from commit b2eaa75) Co-authored-by: sobolevn <[email protected]>
@Eclips4 thank you for your help! |
#126132) [3.12] gh-126105: Fix crash in `ast` module, when `._fields` is deleted (GH-126115) Previously, if the `ast.AST._fields` attribute was deleted, attempts to create a new `as`t node would crash due to the assumption that `_fields` always had a non-NULL value. Now it has been fixed by adding an extra check to ensure that `_fields` does not have a NULL value (this can happen when you manually remove `_fields` attribute). (cherry picked from commit b2eaa75) Co-authored-by: sobolevn <[email protected]>
python#126115) Previously, if the `ast.AST._fields` attribute was deleted, attempts to create a new `as`t node would crash due to the assumption that `_fields` always had a non-NULL value. Now it has been fixed by adding an extra check to ensure that `_fields` does not have a NULL value (this can happen when you manually remove `_fields` attribute).
python#126115) Previously, if the `ast.AST._fields` attribute was deleted, attempts to create a new `as`t node would crash due to the assumption that `_fields` always had a non-NULL value. Now it has been fixed by adding an extra check to ensure that `_fields` does not have a NULL value (this can happen when you manually remove `_fields` attribute).
This PR changes the logic a bit, but it looks like a correct thing to me.
Previously we were handling
NULL
offields
case forremaining_fields
cpython/Python/Python-ast.c
Lines 5089 to 5098 in 9b14083
But, we didn't really handle the
fields
itself.Further calls assume that
fields
cannot beNULL
.The other way of fixing this is to add a default for
fields
like:In this case
ast.AST(arg=1)
with no_fields
will produce:It does not seem correct to me, because
_fields
is a part of our API. SinceAST
objects are mostly internal, there are no real cases of missing_fields
.