gc.get_referrers() can be used to see objects before they are fully built

Crash report

That the problem is occurring in the Py_INCREF macro, it looks like that the error occurs because the code is trying to increment the reference count of an object that doesnt exist.

Steps to reproduce the behavior:
1.create a sample file that contains:

import gc

def g():
    marker = object()
    yield marker
    [tup] = [x for x in gc.get_referrers(marker) if type(x) is tuple]
    print(tup)
    print(tup[1])

tuple(g())

2. just run without opt:

./target/python/Python-3.11.1/builded/bin/python3.11 ./target/python/founded/sig11_sync_Python3111_52.py

Error messages

stderr:

(<object object at 0x7f9e66d10160>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>, <NULL>)
Segmentation fault (core dumped)

gdb:

After run with synthetical sample, binary file aborted with Segfault:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  Py_INCREF (op=0x0) at ./Include/object.h:502

warning: Source file is more recent than executable.
502	#ifdef Py_REF_DEBUG

Expected behavior

No assertion failed.

Additional context

For solution this problem added additional checking to ensure that the op argument is not a null pointer before trying to increment its reference count.

    if (op == NULL) {
        return;
    }

(also added in a patch)

Environment

• Tested on: Python 3.11.1
• Operating system and architecture: Centos-based system (RED OS release MUROM (7.3.2)) ; 5.15.78-2.el7.3.x86_64

Linked PRs

• gh-101856

Reproduce the issue with the Python example using gc.get_referrers() and tuple(g()), then inspect Include/object.h at the Py_INCREF location named in the report. Compare the observed NULL entries and segmentation fault with linked PR gh-101856; done means the reproducer no longer exposes invalid tuple entries or crashes.