Skip to content

Commit cd1dd10

Browse files
Drop an old workaround for previously shared objects.
1 parent 850059a commit cd1dd10

File tree

1 file changed

+3
-28
lines changed

1 file changed

+3
-28
lines changed

Modules/gcmodule.c

+3-28
Original file line numberDiff line numberDiff line change
@@ -2174,41 +2174,16 @@ _PyGC_DumpShutdownStats(PyInterpreterState *interp)
21742174
}
21752175

21762176

2177-
static void
2178-
gc_fini_untrack(PyGC_Head *list)
2179-
{
2180-
PyGC_Head *gc;
2181-
for (gc = GC_NEXT(list); gc != list; gc = GC_NEXT(list)) {
2182-
PyObject *op = FROM_GC(gc);
2183-
_PyObject_GC_UNTRACK(op);
2184-
// gh-92036: If a deallocator function expect the object to be tracked
2185-
// by the GC (ex: func_dealloc()), it can crash if called on an object
2186-
// which is no longer tracked by the GC. Leak one strong reference on
2187-
// purpose so the object is never deleted and its deallocator is not
2188-
// called.
2189-
Py_INCREF(op);
2190-
}
2191-
}
2192-
2193-
21942177
void
21952178
_PyGC_Fini(PyInterpreterState *interp)
21962179
{
21972180
GCState *gcstate = &interp->gc;
21982181
Py_CLEAR(gcstate->garbage);
21992182
Py_CLEAR(gcstate->callbacks);
22002183

2201-
if (!_Py_IsMainInterpreter(interp)) {
2202-
// bpo-46070: Explicitly untrack all objects currently tracked by the
2203-
// GC. Otherwise, if an object is used later by another interpreter,
2204-
// calling PyObject_GC_UnTrack() on the object crashs if the previous
2205-
// or the next object of the PyGC_Head structure became a dangling
2206-
// pointer.
2207-
for (int i = 0; i < NUM_GENERATIONS; i++) {
2208-
PyGC_Head *gen = GEN_HEAD(gcstate, i);
2209-
gc_fini_untrack(gen);
2210-
}
2211-
}
2184+
/* We expect that none of this interpreters objects are shared
2185+
with other interpreters.
2186+
See https://github.com/python/cpython/issues/90228. */
22122187
}
22132188

22142189
/* for debugging */

0 commit comments

Comments
 (0)