GeezerVison

@sergey-miryanov, could you please review this PR?

The reported issue is a leak when modifying structseq types. But this PR changes how structseq instances are tracked by the GC. Can you explain me the relationship between the two?

The reported issue is a leak when modifying structseq types. But this PR changes how structseq instances are tracked by the GC. Can you explain me the relationship between the two?

They are the same bug. Modifying the type creates the cycle type -> tp_dict -> t -> type. It leaks because t is untracked, so the GC cannot see the t -> type edge. Tracking the instance makes that edge visible and lets the GC collect the cycle.

See also #157447 change which is limited to sys.unraisablehook.

Claude initially wrote exactly this change. But it is potentially breaking, the following PyObject_GC_Track() in the user code will crash.

Claude initially wrote exactly this change. But it is potentially breaking, the following PyObject_GC_Track() in the user code will crash.

But the fix in your PR doesn't resolve the leak from my issue.

But the fix in your PR doesn't resolve the leak from my issue.

Your both issues have a common root but fix from #157447 shouldn't fix your issue.

Friendly ping @serhiy-storchaka @vstinner — what's the plan here?

Sadly, changing the public PyStructSequence_New() C API sounds dangerous. As @serhiy-storchaka wrote, it can break existing C extensions which call PyObject_GC_Track().

You can change internal C APIs or modify stdlib extensions to call PyObject_GC_Track() after PyStructSequence_New(). I'm not sure of what's the best approach.

Also, if it's recommended to track objects created by PyStructSequence_New() in the GC, you should mention it in PyStructSequence_New() documentation.

Should I revert the PyStructSequence_New() change, add PyObject_GC_Track() to stdlib callers (time, os, etc.) similar to #157447, and document the tracking requirement in PyStructSequence_New() docs?

Should I revert the PyStructSequence_New() change, add PyObject_GC_Track() to stdlib callers (time, os, etc.) similar to #157447, and document the tracking requirement in PyStructSequence_New() docs?

Yes, but only add PyObject_GC_Track() if an object can contains other objects which can be involved in a reference cycle.

@vstinner Done. Reverted changes to PyStructSequence_New(), added PyObject_GC_Track() to time.struct_time and sys.get_asyncgen_hooks(), documented the requirement in PyStructSequence_New() docs, and updated tests.

Instead, the type should be made immutable: #157176 (comment).

AFAIK only the argument of sys.unraisablehook contains other objects which can be involved in a reference cycle (this is #157447).

The Docs CI failed with:

      File "/home/runner/work/cpython/cpython/Doc/venv/lib/python3.14/site-packages/sphinx/builders/changes.py", line 61, in write_documents
        ttext = self.typemap[changeset.type]
                ~~~~~~~~~~~~^^^^^^^^^^^^^^^^
    KeyError: 'soft-deprecated'

Let me update the branch to see if it does fix the issue.

I enabled auto-merged, please don't touch the PR (your branch) anymore.

Thanks for support.check_immutable_type(self, type(time.gmtime())). The intent of the test is now more obvious (at least,to me).

Merged. Thanks for your fix.