[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