]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
Backport two patches that belong together:
authorGuido van Rossum <guido@python.org>
Mon, 10 Jun 2002 16:02:44 +0000 (16:02 +0000)
committerGuido van Rossum <guido@python.org>
Mon, 10 Jun 2002 16:02:44 +0000 (16:02 +0000)
commit8418a99f37c88b061752c7b862bf73e4c6f0ebc5
tree89e401e47f670a44edeb9b7009bc503561188ad7
parentc48d00d6748c584354d5e4e18e58955ffcd70b50
Backport two patches that belong together:

(2.150)
In the recent python-dev thread "Bizarre new test failure", we
discovered that subtype_traverse must traverse the type if it is a
heap type, because otherwise some cycles involving a type and its
instance would not be collected.  Simplest example:
    while 1:
        class C(object): pass
        C.ref = C()
This program grows without bounds before this fix.  (It grows ever
slower since it spends ever more time in the collector.)

Simply adding the right visit() call to subtype_traverse() revealed
other problems.  With MvL's help we re-learned that type_clear()
doesn't have to clear *all* references, only the ones that may not be
cleared by other means.  Careful analysis (see comments in the code)
revealed that only tp_mro needs to be cleared.  (The previous checkin
to this file adds a test for tp_mro==NULL to _PyType_Lookup() that's
essential to prevent crashes due to tp_mro being NULL when
subtype_dealloc() tries to look for a __del__ method.)  The same kind
of analysis also revealed that subtype_clear() doesn't need to clear
the instance dict.

With this fix, a useful property of the collector is once again
guaranteed: a single gc.collect() call will clear out all garbage.
(It didn't always before, which put us on the track of this bug.)

(2.151)
Undo the last chunk of the previous patch, putting back a useful
assert into PyType_Ready(): now that we're not clearing tp_dict, we
can assert that it's non-NULL again.
Objects/typeobject.c