gc.collect() won't always collect as expected

[pitrou]

BPO	4924
Nosy	@loewis, @pitrou

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = None
created_at = <Date 2009-01-12.13:03:33.379>
labels = ['type-bug']
title = "gc.collect() won't always collect as expected"
updated_at = <Date 2011-06-26.19:01:19.047>
user = 'https://github.com/pitrou'

bugs.python.org fields:

activity = <Date 2011-06-26.19:01:19.047>
actor = 'terry.reedy'
assignee = 'none'
closed = False
closed_date = None
closer = None
components = []
creation = <Date 2009-01-12.13:03:33.379>
creator = 'pitrou'
dependencies = []
files = []
hgrepos = []
issue_num = 4924
keywords = []
message_count = 2.0
messages = ['79673', '79674']
nosy_count = 2.0
nosy_names = ['loewis', 'pitrou']
pr_nums = []
priority = 'normal'
resolution = None
stage = 'test needed'
status = 'open'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue4924'
versions = ['Python 2.7', 'Python 3.2', 'Python 3.3']

Linked PRs

• gh-49174: document that the effect of calling gc.collect() during a collection is undefined #104699
• [3.11] gh-49174: document that the effect of calling gc.collect() during a collection is undefined (GH-104699) #104703

[pitrou]

I haven't verified this through any test (actually I'm wondering how to
deterministically reproduce it), but logically there are cases where
gc.collect() (and, similarly, PyGC_Collect()) won't work as advertised.

Specifically, when the GC is asked to collect a given generation but a
younger generation is already being collected, collect() will simply
notice this and return 0. However, only the younger generation will have
been collected, not the generation asked by the user.

It wouldn't take too much effort to make gc.collect() and PyGC_Collect()
truely deterministic.

[loewis]

It should be possible to trigger this by invoking gc.collect in an
__del__ implementation of an object that is attached to a cycle.

However, I don't think this is an important issue; +0 for resolving this
by documenting the status quo (instead of making the implementation
match the documentation).

[iritkatriel]

I think we need to update the docs, but not to commit to the current behaviour. I'll make a patch to say that this is undefined.