[2.7] bpo-33622: Fix issues with handling errors in the GC. (GH-7078) by serhiy-storchaka · Pull Request #7096 · python/cpython

Expand Up @@ -771,10 +771,8 @@ debug_cycle(char *msg, PyObject *op) * garbage list (a Python list), else only the objects in finalizers with * __del__ methods are appended to garbage. All objects in finalizers are * merged into the old list regardless. * Returns 0 if all OK, <0 on error (out of memory to grow the garbage list). * The finalizers list is made empty on a successful return. */ static int static void handle_finalizers(PyGC_Head *finalizers, PyGC_Head *old) { PyGC_Head *gc = finalizers->gc.gc_next; Expand All @@ -789,12 +787,11 @@ handle_finalizers(PyGC_Head *finalizers, PyGC_Head *old)
if ((debug & DEBUG_SAVEALL) || has_finalizer(op)) { if (PyList_Append(garbage, op) < 0) return -1; break; } }
gc_list_merge(finalizers, old); return 0; }
/* Break reference cycles by clearing the containers involved. This is Expand Down Expand Up @@ -1012,7 +1009,7 @@ collect(int generation) * reachable list of garbage. The programmer has to deal with * this if they insist on creating this type of structure. */ (void)handle_finalizers(&finalizers, old); handle_finalizers(&finalizers, old);
/* Clear free list only during the collection of the highest * generation */ Expand Down Expand Up @@ -1436,8 +1433,11 @@ PyGC_Collect(void) if (collecting) n = 0; /* already collecting, don't do anything */ else { PyObject *exc, *value, *tb; collecting = 1; PyErr_Fetch(&exc, &value, &tb); n = collect(NUM_GENERATIONS - 1); PyErr_Restore(exc, value, tb); collecting = 0; }
Expand Down