revision 2.196
date: 2002/12/07 21:39:16; author: tim_one; state: Exp; lines: +27 -28
slot_nb_nonzero(): Another leak uncovered by the sandbox datetime
tests. I found the logic too confusing to follow here, so rewrote more
than was likely absolutely necessary.
Add a refinement to SLOT1BINFULL() that fixes the problem reported in
SF bug #623669: only try (e.g.) __rdiv__ before __div__ if the right
class actually overrides it.
Backport Guido's checkin 2.171:
Disallow class assignment completely unless both old and new are heap
types. This prevents nonsense like 2.__class__ = bool or
True.__class__ = int.
In inherit_slots(), get rid of the COPYSLOT(tp_dictoffset). Copying
the offset from a non-dominant base makes no sense: either the
non-dominant base has a nonzero tp_dictoffset, and then we should have
already copied it from the dominant base (at the very end of
inherit_special()), or the non-dominant base has no tp_dictoffset and
for some reason type_new() decided not to add one. The tp_dictoffset
from a non-dominant base is likely to conflict with the instance
layout of the dominant base, so copying the tp_dictoffset from the
non-dominant base would be a really bad idea in that case. This bug
can only be triggered by multiple inheritance from an extension class
that doesn't set tp_dictoffset and a new-style user-level class that
does have one. There are no such extension classes in the
distribution, but there are 3rd party ones. (Zope3 now has one,
that's how I found this. :-)
I've asked a few heavy users of new-style classes, extension classes
and metaclasses (David Abrahams and Kevin Jacobs), and neither of them
found any problems in their test suite after applying this fix, so I
assume it's safe.
- Changed new-style class instantiation so that when C's __new__
method returns something that's not a C instance, its __init__ is
not called. [SF bug #537450]
XXX This is arguably a semantic change, but it's hard to imagine a
reason for wanting to depend on the old behavior. If problems with
this are reported within a week of the release of 2.2.2 beta 1, we may
revert this change.
If the object is an ExtensionClass, for example, the slot is not even
defined. So we must check that the type has the slot (implied by
HAVE_CLASS) before calling tp_init().
__del__ method died with
Fatal Python error: GC object already in linked list
in both release and debug builds. Fixed that. Added a new test that
dies without the fix.
Patch from SF bug 570483 (Tim Northover).
In a fresh interpreter, type.mro(tuple) would segfault, because
PyType_Ready() isn't called for tuple yet. To fix, call
PyType_Ready(type) if type->tp_dict is NULL.
Inexplicably, recurse_down_subclasses() was comparing the object
gotten from a weak reference to NULL instead of to None. This caused
the following assert() to fail (but only in 2.2 in the debug build --
I have to find a better test case).
(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.
Three's a charm: yet another fix for SF bug 551412. Thinking again
about the test case, slot_nb_power gets called on behalf of its second
argument, but with a non-None modulus it wouldn't check this, and
believes it is called on behalf of its first argument. Fix this
properly, and get rid of the code in _PyType_Lookup() that tries to
call _PyType_Ready(). But do leave a check for a NULL tp_mro there,
because this can still legitimately occur.
Address SF bug 519621: slots weren't traversed by GC.
While I was at it, I added a tp_clear handler and changed the
tp_dealloc handler to use the clear_slots helper for the tp_clear
handler.
Also set mp->flags = READONLY for the __weakref__ pseudo-slot.
[Note that I am *not* backporting the part of that patch that
tightened the __slot__ rules.]
Address the residual issue with the fix for SF 551412 in
_PyType_Lookup(). Decided to clear the error condition in the
unfortunate but unlikely case that PyType_Ready() fails.
SF bug #541883 (Vincent Fiack).
A stupid bug in object_set_class(): didn't check for value==NULL
before checking its type.
Bugfix candidate.
Original patches were:
python/dist/src/Objects/typeobject.c:2.142
