Skip to content
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

PyCapsule use of tp_traverse is likely unsafe #124684

Closed
nascheme opened this issue Sep 27, 2024 · 1 comment
Closed

PyCapsule use of tp_traverse is likely unsafe #124684

nascheme opened this issue Sep 27, 2024 · 1 comment
Labels
type-bug An unexpected behavior, bug, or error

Comments

@nascheme
Copy link
Member

nascheme commented Sep 27, 2024

Bug report

Bug description:

Switching out the tp_traverse type pointer based on the object type being encapsulated seems unsafe to me. The GC is not prepared for tp_traverse to be changing like that. For example, it assumes that tp_traverse works the same during the different stages of a collection run. I would guess that _PyCapsule_SetTraverse() could possibly be set from a finalizer, for example.

More investigation is needed to determine how we can implement the GC support (so we don't have leaks of _socket objects) but also don't abuse tp_traverse in unsafe ways. One option: have a different PyCapsule type depending on what's wrapped. Second option: have a fixed tp_traverse function but put logic inside of it to determine what the type of the wrapped thing is and do the correct traversal.

gh-124538
gh-108240

@nascheme nascheme added the type-bug An unexpected behavior, bug, or error label Sep 27, 2024
@nascheme
Copy link
Member Author

On further inspection, I think what PyCapsule is doing is actually okay. I had missed that the instance object has traverse_func and clear_func slots on it. So the type doesn't have the slots changing like I thought it did.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

1 participant