Skip to content

bpo-33930: Fix segfault with deep recursion when cleaning method objects #27678

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

Merged
merged 4 commits into from
Aug 10, 2021

Conversation

pablogsal
Copy link
Member

@pablogsal pablogsal commented Aug 9, 2021

https://bugs.python.org/issue33930

Co-authored by Augusto Goulart

Copy link
Member

@vstinner vstinner left a comment

Choose a reason for hiding this comment

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

LGTM. But I have a few minor comments.

Copy link
Member

@vstinner vstinner left a comment

Choose a reason for hiding this comment

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

LGTM.

@@ -160,7 +160,10 @@ PyCMethod_GetClass(PyObject *op)
static void
meth_dealloc(PyCFunctionObject *m)
{
_PyObject_GC_UNTRACK(m);
// The Py_TRASHCAN mechanism requires that we be able to
// call PyObject_GC_UnTrack twice on an object.
Copy link
Member

Choose a reason for hiding this comment

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

I don't understand that, but thanks for the comment!

Copy link
Contributor

@ambv ambv Aug 10, 2021

Choose a reason for hiding this comment

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

@tim-one added this comment in 803526b but the original change is by @nascheme, committed by @gvanrossum in ff413af with the following description:

    This is Neil's fix for SF bug 535905 (Evil Trashcan and GC interaction).

    The fix makes it possible to call PyObject_GC_UnTrack() more than once
    on the same object, and then move the PyObject_GC_UnTrack() call to
    *before* the trashcan code is invoked.

The "SF bug" is also available on BPO: https://bugs.python.org/issue535905

Copy link
Member

Choose a reason for hiding this comment

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

If the comment is unclear, maybe we should try to improve it. I believe the main point is that, since the object uses the trashcan, the function version of untrack is used rather than the macro version. The macro is not safe to call twice because it assumes the object is a part of the GC double linked list. At least, that's my memory of it.

Why the trashcan calls untrack more than once is obscure and I don't recall why it does so. I would need to study the code. My guess would be because it (ab)uses the GC head pointers to store the object in a special trashcan linked list.

Copy link
Member

Choose a reason for hiding this comment

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

Maybe it would be more clear if you would say that the code before Py_TRASHCAN_BEGIN can be executed more than once. Calling the macro version of untrack twice is not safe while the function version is safe.

…30.--5LQ-.rst

Co-authored-by: Łukasz Langa <lukasz@langa.pl>
@miss-islington
Copy link
Contributor

Thanks @pablogsal for the PR 🌮🎉.. I'm working now to backport this PR to: 3.8.
🐍🍒⛏🤖

@miss-islington
Copy link
Contributor

Thanks @pablogsal for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9.
🐍🍒⛏🤖

@miss-islington
Copy link
Contributor

Thanks @pablogsal for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10.
🐍🍒⛏🤖

@miss-islington
Copy link
Contributor

Sorry, @pablogsal, I could not cleanly backport this to 3.8 due to a conflict.
Please backport using cherry_picker on command line.
cherry_picker bfc2d5a5c4550ab3a2fadeb9459b4bd948ff61a2 3.8

@miss-islington
Copy link
Contributor

Sorry @pablogsal, I had trouble checking out the 3.9 backport branch.
Please backport using cherry_picker on command line.
cherry_picker bfc2d5a5c4550ab3a2fadeb9459b4bd948ff61a2 3.9

@bedevere-bot
Copy link

GH-27719 is a backport of this pull request to the 3.10 branch.

@bedevere-bot bedevere-bot removed the needs backport to 3.10 only security fixes label Aug 10, 2021
@pablogsal pablogsal removed the needs backport to 3.9 only security fixes label Aug 10, 2021
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Aug 10, 2021
…cts (pythonGH-27678)

(cherry picked from commit bfc2d5a)

Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
@pablogsal pablogsal added the needs backport to 3.9 only security fixes label Aug 10, 2021
@miss-islington
Copy link
Contributor

Thanks @pablogsal for the PR 🌮🎉.. I'm working now to backport this PR to: 3.9.
🐍🍒⛏🤖

@bedevere-bot
Copy link

GH-27720 is a backport of this pull request to the 3.9 branch.

@bedevere-bot bedevere-bot removed the needs backport to 3.9 only security fixes label Aug 10, 2021
miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Aug 10, 2021
…cts (pythonGH-27678)

(cherry picked from commit bfc2d5a)

Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
@pablogsal
Copy link
Member Author

@ambv do you want to backport this to 3.8?

vstinner pushed a commit that referenced this pull request Aug 11, 2021
…cts (GH-27678) (GH-27720)

(cherry picked from commit bfc2d5a)

Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
vstinner pushed a commit that referenced this pull request Aug 11, 2021
…cts (GH-27678) (GH-27719)

(cherry picked from commit bfc2d5a)

Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
ambv pushed a commit to ambv/cpython that referenced this pull request Aug 11, 2021
…d objects (pythonGH-27678).

(cherry picked from commit bfc2d5a)

Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
@bedevere-bot
Copy link

GH-27721 is a backport of this pull request to the 3.8 branch.

ambv added a commit that referenced this pull request Aug 11, 2021
…d objects (GH-27678) (GH-27721)

(cherry picked from commit bfc2d5a)

Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
michael-o pushed a commit to michael-o/cpython that referenced this pull request Aug 16, 2021
…d objects (pythonGH-27678) (pythonGH-27721)

(cherry picked from commit bfc2d5a)

Co-authored-by: Pablo Galindo Salgado <Pablogsal@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants