This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author tim.peters
Recipients Guido.van.Rossum, gvanrossum, inglesp, pitrou, tim.golden, tim.peters, vstinner
Date 2014-05-06.23:22:18
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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


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).
Date User Action Args
2014-05-06 23:22:19tim.peterssetrecipients: + tim.peters, gvanrossum, pitrou, vstinner, tim.golden, inglesp, Guido.van.Rossum
2014-05-06 23:22:19tim.peterssetmessageid: <>
2014-05-06 23:22:19tim.peterslinkissue21435 messages
2014-05-06 23:22:18tim.peterscreate