-
-
Notifications
You must be signed in to change notification settings - Fork 30.9k
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
Non-thread-safe use of Py_SET_REFCNT
in destructors
#127582
Labels
topic-free-threading
type-bug
An unexpected behavior, bug, or error
type-crash
A hard crash of the interpreter, possibly with a core dump
Comments
colesbury
added
type-bug
An unexpected behavior, bug, or error
topic-free-threading
type-crash
A hard crash of the interpreter, possibly with a core dump
labels
Dec 3, 2024
colesbury
added a commit
to colesbury/cpython
that referenced
this issue
Dec 4, 2024
…ing. Objects may be temporarily "resurrected" in destructors when calling finalizers or watcher callbacks. We previously undid the resurrection by decrementing the reference count using `Py_SET_REFCNT`. This was not thread-safe because other threads might be accessing the object (modifying its reference count) if it was exposed by the finalizer, watcher callback, or temporarily accessed by a racy dictionary or list access. This adds internal-only thread-safe functions for temporary object resurrection during destructors.
colesbury
added a commit
that referenced
this issue
Dec 5, 2024
…H-127612) Objects may be temporarily "resurrected" in destructors when calling finalizers or watcher callbacks. We previously undid the resurrection by decrementing the reference count using `Py_SET_REFCNT`. This was not thread-safe because other threads might be accessing the object (modifying its reference count) if it was exposed by the finalizer, watcher callback, or temporarily accessed by a racy dictionary or list access. This adds internal-only thread-safe functions for temporary object resurrection during destructors.
colesbury
added a commit
to colesbury/cpython
that referenced
this issue
Dec 5, 2024
… threading. (pythonGH-127612) Objects may be temporarily "resurrected" in destructors when calling finalizers or watcher callbacks. We previously undid the resurrection by decrementing the reference count using `Py_SET_REFCNT`. This was not thread-safe because other threads might be accessing the object (modifying its reference count) if it was exposed by the finalizer, watcher callback, or temporarily accessed by a racy dictionary or list access. This adds internal-only thread-safe functions for temporary object resurrection during destructors. (cherry picked from commit f4f5308) Co-authored-by: Sam Gross <[email protected]>
colesbury
added a commit
that referenced
this issue
Dec 5, 2024
…ding. (GH-127612) (GH-127659) Objects may be temporarily "resurrected" in destructors when calling finalizers or watcher callbacks. We previously undid the resurrection by decrementing the reference count using `Py_SET_REFCNT`. This was not thread-safe because other threads might be accessing the object (modifying its reference count) if it was exposed by the finalizer, watcher callback, or temporarily accessed by a racy dictionary or list access. This adds internal-only thread-safe functions for temporary object resurrection during destructors. (cherry picked from commit f4f5308)
srinivasreddy
pushed a commit
to srinivasreddy/cpython
that referenced
this issue
Jan 8, 2025
…ing. (pythonGH-127612) Objects may be temporarily "resurrected" in destructors when calling finalizers or watcher callbacks. We previously undid the resurrection by decrementing the reference count using `Py_SET_REFCNT`. This was not thread-safe because other threads might be accessing the object (modifying its reference count) if it was exposed by the finalizer, watcher callback, or temporarily accessed by a racy dictionary or list access. This adds internal-only thread-safe functions for temporary object resurrection during destructors.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
topic-free-threading
type-bug
An unexpected behavior, bug, or error
type-crash
A hard crash of the interpreter, possibly with a core dump
Bug report
When calling finalizers from dealloc, we temporarily increase the refcount with
Py_SET_REFCNT
and then decrease it again (also withPy_SET_REFCNT
). This isn't thread-safe in the free threading build because some other thread may concurrently try to increase the refcount during a racy dictionary or list access.cpython/Objects/object.c
Lines 552 to 566 in dabcecf
We have similar issues with some watcher events:
cpython/Objects/funcobject.c
Lines 1095 to 1102 in dabcecf
This can lead to crashes when we have racy accesses to objects that may be concurrently finalized. For example:
(Observed more frequently on macOS, but also occurs on Linux)
In macOS buildbot: https://buildbot.python.org/#/builders/1368/builds/2251/steps/6/logs/stdio
Linked PRs
The text was updated successfully, but these errors were encountered: