gh-130202: Fix bug in _PyObject_ResurrectEnd in free threaded build
#130281
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
colesbury
added
skip news
🔨 test-with-refleak-buildbots
colesbury
added
🔨 test-with-refleak-buildbots
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
… build This fixes a fairly subtle bug involving finalizers and resurrection in debug free threaded builds: if `_PyObject_ResurrectEnd` returns `1` (i.e., the object was resurrected by a finalizer), it's not safe to access the object because it might still be deallocated. For example: * The finalizer may have exposed the object to another thread. That thread may hold the last reference and concurrently deallocate it any time after `_PyObject_ResurrectEnd()` returns `1`. * `_PyObject_ResurrectEnd()` may call `_Py_brc_queue_object()`, which may internally deallocate the object immediately if the owning thread is dead. Therefore, it's important not to access the object after it's resurrected. We only violate this in two cases, and only in debug builds: * We assert that the object is tracked appropriately. This is now moved up betewen the finalizer and the `_PyObject_ResurrectEnd()` call. * The `--with-trace-refs` builds may need to remember the object if it's resurrected. This is now handled by `_PyObject_ResurrectStart()` and `_PyObject_ResurrectEnd()`. Note that `--with-trace-refs` is currently disabled in `--disable-gil` builds because the refchain hash table isn't thread-safe, but this refactoring avoids an additional thread-safety issue.
colesbury
force-pushed
the
gh-130202-resurrect
branch
from
a6dc1d7 to
bfac5b2
Compare
colesbury
removed
the
🔨 test-with-refleak-buildbots
colesbury
added
🔨 test-with-refleak-buildbots
|
|
Not sure what's going on with the failure here - there was a failure trying to initialise a sub interpreter. The subsequent CI run passed without error. |
seehwan
pushed a commit
to seehwan/cpython
that referenced
this pull request
Apr 16, 2025
… build (pythongh-130281) This fixes a fairly subtle bug involving finalizers and resurrection in debug free threaded builds: if `_PyObject_ResurrectEnd` returns `1` (i.e., the object was resurrected by a finalizer), it's not safe to access the object because it might still be deallocated. For example: * The finalizer may have exposed the object to another thread. That thread may hold the last reference and concurrently deallocate it any time after `_PyObject_ResurrectEnd()` returns `1`. * `_PyObject_ResurrectEnd()` may call `_Py_brc_queue_object()`, which may internally deallocate the object immediately if the owning thread is dead. Therefore, it's important not to access the object after it's resurrected. We only violate this in two cases, and only in debug builds: * We assert that the object is tracked appropriately. This is now moved up betewen the finalizer and the `_PyObject_ResurrectEnd()` call. * The `--with-trace-refs` builds may need to remember the object if it's resurrected. This is now handled by `_PyObject_ResurrectStart()` and `_PyObject_ResurrectEnd()`. Note that `--with-trace-refs` is currently disabled in `--disable-gil` builds because the refchain hash table isn't thread-safe, but this refactoring avoids an additional thread-safety issue.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This fixes a fairly subtle bug involving finalizers and resurrection in debug free threaded builds: if
_PyObject_ResurrectEndreturns1(i.e., the object was resurrected by a finalizer), it's not safe to access the object because it might still be deallocated. For example:_PyObject_ResurrectEnd()returns1._PyObject_ResurrectEnd()may call_Py_brc_queue_object(), which may internally deallocate the object immediately if the owning thread is dead.Therefore, it's important not to access the object after it's resurrected. We only violate this in two cases, and only in debug builds:
We assert that the object is tracked appropriately. This is now moved up betewen the finalizer and the
_PyObject_ResurrectEnd()call.The
--with-trace-refsbuilds may need to remember the object if it's resurrected. This is now handled by_PyObject_ResurrectStart()and_PyObject_ResurrectEnd().Note that
--with-trace-refsis currently disabled in--disable-gilbuilds because the refchain hash table isn't thread-safe, but this refactoring avoids an additional thread-safety issue._PyObject_ResurrectEndmay deallocate object in the "resurrection" case #130202