[Python-Dev] subtype_dealloc needs rethinking

Tim Peters tim at zope.com
Thu Nov 13 17:18:19 EST 2003


[Armin Rigo]
> If all these ways involve the GC,

Jim's problem does not, but all the "subtype_dealloc vs weakref callback vs
cyclic gc" segfaults did.

> a solution that would avoid similar problems in potentially other
> deallocators might be to fix the GC instead:
>
>>       incref
>>       call tp_clear
>>       decref
>
> This is the only place where the GC explicitely changes reference
> counters.
> It could just be skipped for objects with null refcount.

I really don't like that, because gc isn't broken -- an object with refcount
0 is trash by any reasonable meaning of the word.  What I intend to do in
2.4 instead is include a new assert near the start of gc, to verify that
none of the refcounts it sees are 0 coming in.  That should never happen,
the way Python's gc works.

> As the GC is the only piece of code that should be able to handle
> objects with refcounts of zero (apart from deallocators, but we assume
> these ones know what they are doing) this would fix the double-
> deallocation issue

I agree that it would.

> without making subtype_dealloc even more hairy.

But subtype_dealloc will never be simple or clear, so if obscure cruft has
to be added, I'd rather add it there.  Adding a strange special case to gc
would spread the obscurity, but it's not a goal to make everything at least
a little obscure <wink>.  Thanks to Neil Schemenauer, the gc code today is
remarkably clean and clear.  Thanks to Guido, subtype_dealloc is about as
clear as it can be <wink>.

I just checked in another patch for the sequence of problems Thomas Heller
is seeing, and I think the final result leaves subtype_dealloc exactly as
obscure as it was in 2.3:  all this "real fix" amounts to is moving down a
line of code to near the end of the function (that's the line retracking
self with GC -- it used to do this long before it was necessary to do it,
and now it delays doing it until it's actually needed, which is beyond all
the code where it's dangerous to do it).




More information about the Python-Dev mailing list