gh-142476: fix memory leak when creating JIT executors

Misc/NEWS.d/next/Core_and_Builtins/2025-12-13-01-11-03.gh-issue-142476.44Sp4N.rst

@@ -0,0 +1,2 @@
+Fix a memory leak in the experimental Tier 2 optimizer when creating
+executors. Patched by Shamil Abdulaev.

Python/optimizer.c

@@ -185,12 +185,16 @@ _PyOptimizer_Optimize(
     else {
         executor->vm_data.code = NULL;
     }
+    executor->vm_data.chain_depth = chain_depth;
+    assert(executor->vm_data.valid);
     _PyExitData *exit = _tstate->jit_tracer_state.initial_state.exit;
     if (exit != NULL) {
         exit->executor = executor;
+    } else {
+        // An executor inserted into the code object now has a strong reference
+        // to it from the code object. Thus, we don't need this reference anymore.
+        Py_DECREF(executor);
     }
-    executor->vm_data.chain_depth = chain_depth;
-    assert(executor->vm_data.valid);
     interp->compiling = false;
     return 1;
 #else
@@ -310,7 +314,13 @@ add_to_pending_deletion_list(_PyExecutorObject *self)
 static void
 uop_dealloc(PyObject *op) {
     _PyExecutorObject *self = _PyExecutorObject_CAST(op);
-    _PyObject_GC_UNTRACK(self);
+
+    // Object might be already untracked if we are in a GC cycle (via tp_clear).
+    // Avoid double-untracking.
+    if (_PyObject_GC_IS_TRACKED(self)) {
+        _PyObject_GC_UNTRACK(self);
+    }
+
     assert(self->vm_data.code == NULL);
     unlink_executor(self);
     // Once unlinked it becomes impossible to invalidate an executor, so do it here.