When Py_TRACE_REFS is defined, a list of all live objects is maintained in
a doubly-linked list, exposed by sys.getobjects(). Unfortunately, it's not
really all live objects, and it seems my fate to bump into programs where
sys.gettotalrefcount() keeps going up but where the reference leaks aren't
accounted for by anything in the list of all objects.
This patch helps a little: if COUNT_ALLOCS is also defined, from now on
type objects will also appear in this list, provided at least one object
of a type has been allocated.
diff --git a/Misc/SpecialBuilds.txt b/Misc/SpecialBuilds.txt
index a4226c9..a3d3558 100644
--- a/Misc/SpecialBuilds.txt
+++ b/Misc/SpecialBuilds.txt
@@ -34,10 +34,14 @@
Turn on heavy reference debugging. This is major surgery. Every PyObject
grows two more pointers, to maintain a doubly-linked list of all live
-heap-allocated objects (note that, e.g., most builtin type objects are not
-in this list, as they're statically allocated). Note that because the
-fundamental PyObject layout changes, Python modules compiled with
-Py_TRACE_REFS are incompatible with modules compiled without it.
+heap-allocated objects. Most builtin type objects are not in this list,
+as they're statically allocated. Starting in Python 2.3, if COUNT_ALLOCS
+(see below) is also defined, a static type object T does appear in this
+list if at least one object of type T has been created.
+
+Note that because the fundamental PyObject layout changes, Python modules
+compiled with Py_TRACE_REFS are incompatible with modules compiled without
+it.
Py_TRACE_REFS implies Py_REF_DEBUG.
@@ -171,6 +175,11 @@
all heap-allocated type objects immortal, except for those for which no
object of that type is ever allocated.
+Starting with Python 2.3, If Py_TRACE_REFS is also defined, COUNT_ALLOCS
+arranges to ensure that the type object for each allocated object
+appears in the doubly-linked list of all objects maintained by
+Py_TRACE_REFS.
+
Special gimmicks:
sys.getcounts()