gh-126105: Fix crash in ast module, when ._fields is deleted#126115
gh-126105: Fix crash in ast module, when ._fields is deleted#126115Eclips4 merged 2 commits intopython:mainfrom
ast module, when ._fields is deleted#126115Conversation
picnixz
left a comment
There was a problem hiding this comment.
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 |
| 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.
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 <mail@sobolevn.me>
|
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 <mail@sobolevn.me>
|
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 <mail@sobolevn.me>
|
@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 <mail@sobolevn.me>
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
NULLoffieldscase forremaining_fieldscpython/Python/Python-ast.c
Lines 5089 to 5098 in 9b14083
But, we didn't really handle the
fieldsitself.Further calls assume that
fieldscannot beNULL.The other way of fixing this is to add a default for
fieldslike:In this case
ast.AST(arg=1)with no_fieldswill produce:It does not seem correct to me, because
_fieldsis a part of our API. SinceASTobjects are mostly internal, there are no real cases of missing_fields.