Skip to content

[3.9] bpo-44562: Remove invalid PyObject_GC_Del from error path of types.GenericAlias … (GH-27016) #27028

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.

Sign up for GitHub

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

Merged
merged 3 commits into from
Jul 5, 2021
Merged

[3.9] bpo-44562: Remove invalid PyObject_GC_Del from error path of types.GenericAlias … (GH-27016) #27028

Show file tree
Hide file tree
Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
d9e432e
bpo-44562: Remove invalid PyObject_GC_Del from error path of types.Ge…
Fidget-Spinner Jul 5, 2021
6082fb9
check if using PyType_GenericAlloc fixes it
Fidget-Spinner Jul 5, 2021
8c2ef51
Update Objects/genericaliasobject.c
Fidget-Spinner Jul 5, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 2 additions & 0 deletions Misc/NEWS.d/next/Core and Builtins/2021-07-04-23-38-51.bpo-44562.QdeRQo.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,2 @@
Remove uses of :c:func:`PyObject_GC_Del` in error path when initializing
:class:`types.GenericAlias`.
8 changes: 4 additions & 4 deletions Objects/genericaliasobject.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -602,7 +602,7 @@ ga_new(PyTypeObject *type, PyObject *args, PyObject *kwds)
return NULL;
}
if (!setup_ga(self, origin, arguments)) {
type->tp_free((PyObject *)self);
Py_DECREF(self);
return NULL;
}
return (PyObject *)self;
Expand Down Expand Up @@ -640,14 +640,14 @@ PyTypeObject Py_GenericAliasType = {
PyObject *
Py_GenericAlias(PyObject *origin, PyObject *args)
{
gaobject *alias = PyObject_GC_New(gaobject, &Py_GenericAliasType);
gaobject *alias = (gaobject*) PyType_GenericAlloc(
(PyTypeObject *)(&Py_GenericAliasType), 0);
if (alias == NULL) {
return NULL;
}
if (!setup_ga(alias, origin, args)) {
PyObject_GC_Del((PyObject *)alias);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dislike the idea of having a code different in 3.9 and main. Why would 3.9 have different code?

It looks like a legit bug which also affects the main branch.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I dislike tracking the object earlier, before it's fully initialized. It goes against https://bugs.python.org/issue44531

I would prefer to track the object if setup_ga() fails, so ga_dealloc() doesn't have to use PyObject_GC_UnTrack() (to not untrack if it is not track).

An alternative is to use PyObject_GC_UnTrack() in ga_dealloc(), only for this code path.

@pablogsal: I also have this issue in https://bugs.python.org/issue44531 Is it a good practice to track an object partially initialized (its traverse function may crash) only to be able to deallocate it?

I didn't check if ga_traverse() can be called (don't crash) if setup_ga() fails. In your PR, you change the function.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code is also like this on the main branch: https://github.com/python/cpython/blob/main/Objects/genericaliasobject.c#L655

This is a backport PR. The only part I changed was this line onwards https://github.com/python/cpython/pull/27028/files#diff-828d12085a29364c67442b193bb62906e3469fbe21367499fd62817f98190014R36.

I'm waiting for Pablo to merge #27021 first. This PR is just to test if I can fix the failures on macOS, because I can't repro them on main or 3.10.

Copy link
Member Author

@Fidget-Spinner Fidget-Spinner Jul 5, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry if I wasn't very clear, a quick summary:

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, the macOS test is still failing, I think you're right here. It's probably triggering GC on improperly initialized object :(.

Copy link
Member

@pablogsal pablogsal Jul 5, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@pablogsal: I also have this issue in https://bugs.python.org/issue44531 Is it a good practice to track an object partially initialized (its traverse function may crash) only to be able to deallocate it?

If you use PyGenericAlloc, the fields are initialized to NULL and the VISIT macro handles that correctly. Is not that is a good or bad practice, is that you cannot deallocate it without tracking using a regular DECREF

Py_DECREF(alias);
return NULL;
}
_PyObject_GC_TRACK(alias);
return (PyObject *)alias;
}