SF bug 578752: COUNT_ALLOCS vs heap types

Repair segfaults and infinite loops in COUNT_ALLOCS builds in the
presence of new-style (heap-allocated) classes/types.

Bugfix candidate.  I'll backport this to 2.2.  It's irrelevant in 2.1.

Misc/NEWS

@@ -294,6 +294,14 @@ Tools/Demos
 
 Build
 
+- 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.
+
 - Compiling out the cyclic garbage collector is no longer an option.
   The old symbol WITH_CYCLE_GC is now ignored, and Python.h arranges
   that it's always defined (for the benefit of any extension modules

Objects/object.c

@@ -74,6 +74,15 @@ inc_count(PyTypeObject *tp)
 		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++;