bpo-42536: GC track recycled tuples

Lib/test/test_builtin.py

@@ -6,6 +6,7 @@
 import collections
 import decimal
 import fractions
+import gc
 import io
 import locale
 import os
@@ -1756,6 +1757,18 @@ def __next__(self):
         l8 = self.iter_error(zip(Iter(3), "AB", strict=True), ValueError)
         self.assertEqual(l8, [(2, "A"), (1, "B")])
 
+    @support.cpython_only
+    def test_zip_result_gc(self):
+        # bpo-42536: zip's tuple-reuse speed trick breaks the GC's assumptions
+        # about what can be un-tracked. Make sure we re-track result tuples
+        # whenever we reuse them.
+        z = zip([[]])
+        gc.collect()
+        # That GC collection probably untracked the recycled internal result
+        # tuple, which is initialized to (None,). Make sure it's re-tracked when
+        # it's mutated and returned from __next__:
+        self.assertTrue(gc.is_tracked(next(z)))
+
     def test_format(self):
         # Test the basic machinery of the format() builtin.  Don't test
         #  the specifics of the various formatters

Misc/NEWS.d/next/Core and Builtins/2020-12-02-20-23-31.bpo-42536.Kx3ZOu.rst

@@ -0,0 +1,3 @@
+:func:`zip` now ensures that its internal result tuple is always tracked by the
+garbage collector. Previously, it could have become untracked by a prior garbage
+collection. Patch by Brandt Bucher.

Python/bltinmodule.c

@@ -2636,6 +2636,12 @@ zip_next(zipobject *lz)
             PyTuple_SET_ITEM(result, i, item);
             Py_DECREF(olditem);
         }
+        // bpo-42536
+        // The GC may have untracked this result tuple if its elements were all
+        // untracked. Since we're recycling it, make sure it's tracked again:
+        if (!_PyObject_GC_IS_TRACKED(result)) {
+            _PyObject_GC_TRACK(result);
+        }
     } else {
         result = PyTuple_New(tuplesize);
         if (result == NULL)