diff options
author | Sam Gross <colesbury@gmail.com> | 2025-02-25 12:03:28 -0500 |
---|---|---|
committer | GitHub <noreply@github.com> | 2025-02-25 12:03:28 -0500 |
commit | f963239ff1f986742d4c6bab2ab7b73f5a4047f6 (patch) | |
tree | 130327a265186bea84cab11272aee3492bc2ed99 /Python/traceback.c | |
parent | c5f925c8c948736bd64652918b4e0186b91abbb5 (diff) | |
download | cpython-f963239ff1f986742d4c6bab2ab7b73f5a4047f6.tar.gz cpython-f963239ff1f986742d4c6bab2ab7b73f5a4047f6.zip |
gh-130202: Fix bug in `_PyObject_ResurrectEnd` in free threaded build (gh-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.
Diffstat (limited to 'Python/traceback.c')
0 files changed, 0 insertions, 0 deletions