-
-
Notifications
You must be signed in to change notification settings - Fork 33.9k
gh-143635: Fix crash in _Py_typing_type_repr
#143670
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
base: main
Are you sure you want to change the base?
Conversation
| return PyUnicodeWriter_WriteASCII(writer, "None", 4); | ||
| } | ||
|
|
||
| Py_INCREF(p); // gh-143635 |
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.
This sort of feels like the wrong place, shouldn't callers of the function ensure they have a reference to p that remains valid?
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 think so and we should just say that the function takes a strong reference (the function is not documented but it would be good to indicate this).
That means changing some PyList_GET_ITEM/PyTuple_GET_ITEM and adding some Py_INCREF for non-sequences.
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.
Hm, I am not quite sure about it. Technically, we don't need a strong reference in regular cases, it is only needed for strange self-destructing ones.
We have multiple places where we just use Py_INCREF / Py_DECREF on a object before calling some python callbacks with it. Changing this function to require a strong refenrence will require quite a lot of refactoring for a very niche thing (and might be a breaking change for anyone using this function, even though it is not documented).
Let's say we want to refactor this place:
cpython/Objects/genericaliasobject.c
Lines 103 to 105 in e22b685
| if (_Py_typing_type_repr(writer, alias->origin) < 0) { | |
| goto error; | |
| } |
It would be:
Py_INCREF(alias->origin);
if (_Py_typing_type_repr(writer, alias->origin) < 0) {
Py_DECREF(alias->origin);
goto error;
}
Py_DECREF(alias->origin);This does not seem like a good API to me :/
What are the potential limitations of the current approach?
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.
Changing this function to require a strong refenrence will require quite a lot of refactoring for a very niche thing (and might be a breaking change for anyone using this function, even though it is not documented).
It's not exported as part of the public API so I'm not sure it's available by "others" (it's only an extern symbol in the internal API). Since it's internal we can also keep your change as it reduces the diff (I didn't think there would be that many places though)
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.
Maybe it is worth to open a separate PR for adding a strong ref?
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.
No I think it should be decided here.
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.
No I think it should be decided here.
|
This needs NEWS since it fixes a user-visible crash. |
I also added one more test case for a second possible crash in the same function.
_Py_typing_type_reprvia re-entrant__origin__lookup duringGenericAliasrepr #143635