This change breaks C extensions which define types with Py_TPFLAGS_HAVE_GC but without tp_traverse, even if instances of the type are never tracked by the GC. Such extensions worked properly previously.

Maybe the check could be restricted to heap types?

If we don't want to break the backward compatibility, we should check in PyObject_GC_Track() if type->tp_traverse is not NULL.

Many instances are created by PyType_GenericAlloc() which calls _PyObject_GC_TRACK(). I tried to modify _PyObject_GC_TRACK() to ensure that it's possible to traverse the instance, as I did in PyObject_GC_Track(), but I got a lot of issues. Many types call _PyObject_GC_TRACK() too early, and it's really difficult to change that (it would require a lot of work).

cc @pablogsal @erlend-aasland @corona10

As I explained at https://bugs.python.org/issue44263#msg394799, this PR cannot be merged yet since _testcapi and _decimal don't respect the GC protocol. I chose to create a separated PR to fix them, so it can be backported (and review should be easier): #26464

Many instances are created by PyType_GenericAlloc() which calls _PyObject_GC_TRACK(). I tried to modify _PyObject_GC_TRACK() to ensure that it's possible to traverse the instance, as I did in PyObject_GC_Track(), but I got a lot of issues. Many types call _PyObject_GC_TRACK() too early, and it's really difficult to change that (it would require a lot of work).

My latest attempt in 2020: https://bugs.python.org/issue40142

@vstinner is the issue number correct?

@vstinner is the issue number correct?

I consider that it's to ok reuse https://bugs.python.org/issue44263 My change implements a runtime check for 8b55bc3 "... it must implement the GC protocol itself by at least including a slot".

PR rebased on top on the merged PR #26464 fix.

I consider that it's to ok reuse https://bugs.python.org/issue44263

🤷‍♂️ I don't know about that, https://bugs.python.org/issue44263 is a bout a documentation change and this is a breaking change in the C-API, which probably requires its own issue. But I don't feel strongly so you don't need to change anything. I just want to note that I find it a bit odd.

For the risk of breaking C extensions with this PR: I documented the change in What's New in Python 3.11. It's the bare minimum change that I can do.

@pablogsal: Apart of the bpo number, are you ok with this change?

A GC type with NULL traverse function is likely to crash, but not always, as we saw with the broken _ssl.SSLError exception ;-) This change makes the code more deterministic, it always fail (but don't crash) ;-)

For the risk of breaking C extensions with this PR: I documented the change in What's New in Python 3.11. It's the bare minimum change that I can do.

Hm. Ptr's pep-652 have redefined the lifetime of stable ABI, so it's not a big probleam, right?
refs: https://www.python.org/dev/peps/pep-0652/#stable-abi

Hm. Ptr's pep-652 have redefined the lifetime of stable ABI, so it's not a big probleam, right?

This doesn't change the ABI, it just makes a bug break early :)

This doesn't change the ABI, it just makes a bug break early :)

OK. It's make sense :)

Ok, I merged my PR. If it breaks too many C extensions, we can revert it. I hope that it will detect more real bugs than it breaks C extensions for no good reasons :-D