RetroSearch Browse

Mon Nov 17 07:24:25 EST 2003 · https://mail.python.org/pipermail/python-dev/2003-November/040276.html

Armin Rigo <arigo at tunes.org> writes:

> Hello Christian,
>
> On Mon, Nov 17, 2003 at 02:02:48AM +0100, Christian Tismer wrote:
>> I debuged this down to the very end, until I was sure
>> my stuff is doing it right. Then I added a small function
>> that recomputes the actual total refcounts from the
>> chained list of all objects, and it turned out to be
>> correct (and also my pickling), but _Py_RefTotal is different.
>
> I found a few places that manipulate ob_refcnt directly without
> worrying about keeping _Py_RefTotal or other debugging information
> in sync:

Um, don't most of these places at least *try* to keep _Py_RefTotal in
sync?  I am aware of a few places that get this wrong, but the fixes
weren't obvious to me.

> * classobject.c:instance_dealloc(), for __del__

One way of getting _Py_RefTotal out of sync is resurrecting objects in
__del__ methods.  Another is some bizarre interaction with the
trashcan machinery (don't recall what, sorry, may also be different
with 2.2 vs 2.3).

> * stringobject.c, for interned strings
>
> * typeobject.c:slot_tp_del(), for __del__ too
>
> I bet you could also find these easily, but maybe it should be regarded as a 
> bug list.  

I think these are bugs.

> At any rate, the __del__ tricks will indeed make some counters
> invalid.

Which __del__ tricks specifically?

Cheers,
mwh

-- 
  Strangely enough  I saw just such a beast at  the grocery store
  last night. Starbucks sells Javachip. (It's ice cream, but that
  shouldn't be an obstacle for the Java marketing people.)
                                         -- Jeremy Hylton, 29 Apr 1997

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2003-November/040276.html below:

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