Tim Peters added the comment:
A bit more info: recall that, when deleting a type object (for class B), the
previous (list) object's gc_next got overwritten with NULL. The new info: its
(the list object's) gc_refs also changed from GC_TENTATIVELY_UNREACHABLE to
GC_UNTRACKED, That the object became untracked is wholly consistent with that
its gc_next became NULL but not its gc_prev.
I haven't tracked it down all the way to the offending code, but I wonder
whether that's worth the bother. What reason do we have to believe that
Py_DECREF(op);
CANNOT cause other objects in the `collectable` list to become recognized as
trash too? We're in cyclic trash, and one decref can trigger an arbitrary
number of other objects to become trash.
So I'll attach a patch that doesn't assume the Py_DECREF is harmless, by moving
`collectable` objects one at a time to a temporary list, and then - at the end
- moves all survivors back to `collectable`. That makes the error go away, but
I can't be certain it's address the real problem (since I stopped looking for
the code that messed with the list as a side effect of doing a decref on the
type object for class B).
----------
keywords: +patch
Added file: http://bugs.python.org/file35165/finalize.patch
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue21435>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
