[Stackless] Re: [Python-Dev] _Py_RefTotal wrong in Py 2.2.3

Tim Peters tim.one at comcast.net
Mon Nov 17 13:02:13 EST 2003


[Michael Hudson]
> This is also why running test_descr in a loop still bumps
> sys.gettotalrefcount() by 3 or so each time.

Ah, so it's critical then <wink -- but, really, it should be fixed>.

[Tim]
>> 		/* If Py_REF_DEBUG, the original decref dropped _Py_RefTotal,
>> 		 * but _Py_NewReference bumped it again, so that's a wash.
>>
>> Heh.  If you ignore the new reference(s) that resurrected the thing,
>> I suppose that would be true.  It should (2.3.2) do
>>
>> 	_Py_DEC_REFTOTAL;
>>
>> to make up for the extra increment done by _Py_NewReference;
>> likewise in slot_tp_del (BTW, the macro expands to nothing if
>> Py_REF_DEBUG isn't defined).


> Is it that easy?

In 2.3.2, it should be.  The code is more convoluted in 2.2.3.  I don't care
about 2.2.n anymore, though, so I'm not going to spend any time looking at
that.

> I remember fooling a little with this, but not successfully.  It's just
> possible <wink> that I got confused, though.  (Confused by finalizer
> issues?  How could that be?)

I hate finalizers.  I'm learning to hate weakref callbacks too.

> FWIW, my foolings were with new-style objects -- but from what you say
> in another post, it's unsurprising to find isomorphic problems with
> old-style classes (as in your example).

Right, Guido did copy+paste of masses of old-style object code into the
new-style object code.  One or two new bugs were introduced that way that I
know of, long since fixed.  This one is a case of duplicating a bug, and it
looks to be as shallow as they get.  Whoever did the last rework of string
interning clearly wasn't thinking about all these "special builds" at all,
so that may be trickier.




More information about the Python-Dev mailing list