(The fix looks different, but does the same thing to the 2.1 GC code
that Neil's patch does to the 2.2 GC code.)
This is Neil's fix for SF bug 535905 (Evil Trashcan and GC interaction).
The fix makes it possible to call PyObject_GC_UnTrack() more than once
on the same object, and then move the PyObject_GC_UnTrack() call to
*before* the trashcan code is invoked.
BUGFIX CANDIDATE!
static void
gc_list_remove(PyGC_Head *node)
{
+ if (node->gc_next == NULL)
+ return;
node->gc_prev->gc_next = node->gc_next;
node->gc_next->gc_prev = node->gc_prev;
#ifdef Py_DEBUG
node->gc_prev = NULL;
- node->gc_next = NULL;
#endif
+ node->gc_next = NULL;
}
static void
{
register int i;
register dictentry *ep;
- Py_TRASHCAN_SAFE_BEGIN(mp)
PyObject_GC_Fini(mp);
+ Py_TRASHCAN_SAFE_BEGIN(mp)
for (i = 0, ep = mp->ma_table; i < mp->ma_size; i++, ep++) {
if (ep->me_key != NULL) {
Py_DECREF(ep->me_key);
list_dealloc(PyListObject *op)
{
int i;
- Py_TRASHCAN_SAFE_BEGIN(op)
PyObject_GC_Fini(op);
+ Py_TRASHCAN_SAFE_BEGIN(op)
if (op->ob_item != NULL) {
/* Do it backwards, for Christian Tismer.
There's a simple test case where somehow this reduces
{
register int i;
register int len = op->ob_size;
- Py_TRASHCAN_SAFE_BEGIN(op)
PyObject_GC_Fini(op);
+ Py_TRASHCAN_SAFE_BEGIN(op)
if (len > 0) {
i = len;
while (--i >= 0)