-
-
Notifications
You must be signed in to change notification settings - Fork 33.9k
gh-144054: shutdown fix for deferred ref counting #144055
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
gh-144054: shutdown fix for deferred ref counting #144055
Conversation
When shutting down, disable deferred refcounting for all GC objects. It is important to do this also for untracked objects, which before this change were getting missed.
We can remove the shutdown case disable_deferred_refcounting() call inside scan_heap_visitor() if we are careful about it. The key is that frame_disable_deferred_refcounting() might fail if the object is untracked.
|
@colesbury I think this is a correct fix but some of the details are a bit tricky. It seems the I split the "disable deferred" into a separate heap scan. Doing it inside |
|
🤖 New build scheduled with the buildbot fleet by @nascheme for commit 296eba9 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F144055%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-refleak-buildbots label again. |
|
The refleak test failure in |
|
Otherwise, buildbots are happy. |
|
I don't think this is right. There shouldn't be any objects that are untracked and use deferred reference counting. |
|
If an object is untracked and and uses deferred reference counting, then it won't be freed when it's no longer referenced. Collecting those objects at shutdown will satisfy the leak tests, but that doesn't fix the actual problem. |
|
I'm working on a correct fix. If |
This reverts pythongh-144055 and fixes the bug in a different way. Deferred reference counting relies on the object being tracked by the GC, otherwise the object will live until interpreter shutdown. So, take care that we do not enable deferred reference counting for objects that are untracked. Also, if a tuple has deferred reference counting enabled, don't untrack it.
This reverts gh-144055 and fixes the bug in a different way. Deferred reference counting relies on the object being tracked by the GC, otherwise the object will live until interpreter shutdown. So, take care that we do not enable deferred reference counting for objects that are untracked. Also, if a tuple has deferred reference counting enabled, don't untrack it.
When shutting down, disable deferred refcounting for all GC objects. It is important to do this also for untracked objects, which before this change were getting missed.