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, larry, pitrou, tim.golden, tim.peters, vstinner
Date 2014-05-07.22:47:10
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
OK!  This has nothing to do with the trashcan mechanism.

The list object whose gc_next gets stomped on is not itself in a cycle.  It's an empty list, and just happens to be a value in a dict, which in turn is a value in another dict.  Its refcount falls to 0 as an ordinary part of its containing dict getting deallocated, and that's why the list becomes untracked.

This was confusing me because the memory for the list object was apparently not deallocated:  if it had been, pymalloc would have sprayed 0xdb into most of it, and gc_next would have appeared to me as 0xdbdbdbdb, not as 0.  But after calling PyObject_GC_UnTrack on it (which sets gc_next to NULL), list_dealloc() just pushed the list object onto a free list, so no other kind of list destruction got done.

That pretty much explains everything.  Cute:  it so happens that the _entire_ `collectable` list gets cleared out as a side effect of a single


call.  The iteration approach in the patch is robust against that, but it's hard to imagine that anything simpler could be.
Date User Action Args
2014-05-07 22:47:10tim.peterssetrecipients: + tim.peters, gvanrossum, pitrou, vstinner, larry, tim.golden, inglesp, Guido.van.Rossum
2014-05-07 22:47:10tim.peterssetmessageid: <>
2014-05-07 22:47:10tim.peterslinkissue21435 messages
2014-05-07 22:47:10tim.peterscreate