Message218089
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
finalize(op);
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:10 | tim.peters | set | recipients:
+ tim.peters, gvanrossum, pitrou, vstinner, larry, tim.golden, inglesp, Guido.van.Rossum |
2014-05-07 22:47:10 | tim.peters | set | messageid: <1399502830.79.0.530722883563.issue21435@psf.upfronthosting.co.za> |
2014-05-07 22:47:10 | tim.peters | link | issue21435 messages |
2014-05-07 22:47:10 | tim.peters | create | |
|