[Python-Dev] _Py_RefTotal wrong in Py 2.2.3
Tim Peters
tim.one at comcast.net
Mon Nov 17 11:36:44 EST 2003
[Armin]
> I found a few places that manipulate ob_refcnt directly without
> worrying about keeping _Py_RefTotal or other debugging information
> in sync:
In which codebase? (2.3.2, 2.3 maint, 2.4, ...?)
> * classobject.c:instance_dealloc(), for __del__
instance_dealloc endures outrageous convolution trying to keep _Py_RefTotal
(and friends) correct, although the code is very different between 2.3.2 and
2.2.3. In 2.3.2:
- If the instance isn't resurrected, then the instance goes away without
fiddling _Py_RefTotal at all. That's correct.
- If it is resurrected, then
/* If Py_REF_DEBUG, the original decref dropped _Py_RefTotal,
* but _Py_NewReference bumped it again, so that's a wash.
* If Py_TRACE_REFS, _Py_NewReference re-added self to the
* object chain, so no more to do there either.
* If COUNT_ALLOCS, the original decref bumped tp_frees, and
* _Py_NewReference bumped tp_allocs: both of those need to
* be undone.
*/
By "the original decref" it means the Py_DECREF that caused the instance's
refcount to fall to 0 in the first place (thus getting us into
instance_dealloc).
> * stringobject.c, for interned strings
Easy to believe that one's screwed up <wink>.
> * typeobject.c:slot_tp_del(), for __del__ too
At least in 2.3.2, that's enduring the same convolutions as instance_dealloc
trying to keep this stuff right.
More information about the Python-Dev
mailing list