Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Fixed reference leak in the finalization of :mod:`tkinter`.
27 changes: 19 additions & 8 deletions Modules/_tkinter.c
Original file line number Diff line number Diff line change
Expand Up @@ -3389,17 +3389,28 @@ DisableEventHook(void)
#endif
}

static int
module_clear(PyObject *mod)
{
Py_CLEAR(Tkinter_TclError);
Py_CLEAR(Tkapp_Type);
Py_CLEAR(Tktt_Type);
Py_CLEAR(PyTclObject_Type);
return 0;
}

static void
module_free(void *mod)
{
module_clear((PyObject *)mod);
}

static struct PyModuleDef _tkintermodule = {
PyModuleDef_HEAD_INIT,
"_tkinter",
NULL,
-1,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You removed .m_size = -1, but it's ok, m_size=0 also means "no module state".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a difference between 0 and -1 related to subinterpreters.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the difference?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From the documentation:

      Setting ``m_size`` to ``-1`` means that the module does not support
      sub-interpreters, because it has global state.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh I see, I forgot about this difference :-(

moduleMethods,
NULL,
NULL,
NULL,
NULL
.m_name = "_tkinter",
.m_methods = moduleMethods,
.m_clear = module_clear,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you define "clear", you should always define "travel".

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to emit a warning or even raise an error at runtime?

For example in Objects/typeobject.c, I added an assertion in _PyType_CheckConsistency():

    if (type->tp_flags & Py_TPFLAGS_HAVE_GC) {
        // bpo-44263: tp_traverse is required if Py_TPFLAGS_HAVE_GC is set.
        // Note: tp_clear is optional.
        CHECK(type->tp_traverse != NULL);
    }

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like a good idea. For both types and modules.

.m_free = module_free
};

PyMODINIT_FUNC
Expand Down