Repair segfaults and infinite loops in COUNT_ALLOCS builds in the
presence of new-style (heap-allocated) classes/types.
Note: test_gc fails in a COUNT_ALLOCS build now, because it expects
a new-style class to get garbage collected.
custom metaclasses the same way it treats instances of type 'type'
[SF patch 560794].
+Build
-C API
+- A bug was fixed that could cause COUNT_ALLOCS builds to segfault, or
+ get into infinite loops, when a new-style class got garbage-collected.
+ Unfortunately, to avoid this, the way COUNT_ALLOCS works requires
+ that new-style classes be immortal in COUNT_ALLOCS builds. Note that
+ COUNT_ALLOCS is not enabled by default, in either release or debug
+ builds, and that new-style classes are immortal only in COUNT_ALLOCS
+ builds. SourceForge bug 578752.
+C API
Windows
if (tp->tp_next != NULL) /* sanity check */
Py_FatalError("XXX inc_count sanity check");
tp->tp_next = type_list;
+ /* Note that as of Python 2.2, heap-allocated type objects
+ * can go away, but this code requires that they stay alive
+ * until program exit. That's why we're careful with
+ * refcounts here. type_list gets a new reference to tp,
+ * while ownership of the reference type_list used to hold
+ * (if any) was transferred to tp->tp_next in the line above.
+ * tp is thus effectively immortal after this.
+ */
+ Py_INCREF(tp);
type_list = tp;
}
tp->tp_allocs++;