Spurious "Type does not define the tp_name field" in 3.13.0rc2t

[dpdani]

Bug report

Bug description:

I'm hitting some (I believe) spurious errors when using my C extension with the latest rc.
Due to the nature of the exception, I would suppose that the build type should not affect it, but it does:

• tests failing in free-threaded build
• tests passing in default build
• the tests pass for the free-threaded build with rc1 (don't have this on CI -- tested locally)

3.13.0rc1 test logs

====================== test session starts =======================
platform linux -- Python 3.13.0rc1, pytest-7.4.2, pluggy-1.5.0
rootdir: /home/dp/repos/thesis/cereggii
plugins: reraise-2.1.2
collected 96 items                                               

tests/test_atomic_dict.py .............s....s.....ss...... [ 33%]
.                                                          [ 34%]
tests/test_atomic_int.py ................................. [ 68%]
.......................                                    [ 92%]
tests/test_atomic_ref.py ......                            [ 98%]
tests/test_basics.py .                                     [100%]

================= 92 passed, 4 skipped in 0.60s ==================

The free-threaded build is using the deadsnakes action, and I believe that's CPython's main from yesterday.

After double-checking, I'm pretty sure I'm setting the tp_name field correctly everywhere, apologies in advance if I made a mistake.

CPython versions tested on:

3.13, CPython main branch

Operating systems tested on:

Linux

[ZeroIntensity]

At a quick glance, it looks like this type object is missing tp_name: https://github.com/dpdani/cereggii/blob/e887f1f060ad94ceb8e16b6ab2f62f29c7a1d8ea/src/include/atomic_dict_internal.h#L47

Though, I'm not sure why this only occurs on the free-threaded build.

[dpdani]

After removing it (commit), it's still failing with the same error message.
(It wasn't being used.)

Thanks for the catch anyways, that's something I needed to clean up.

[ZeroIntensity]

Could you narrow this down to what class is causing this? I'm hesitant to mark this as a blocker because we don't have a proper reproducer yet.

[dpdani]

I've tried commenting everything except for:

• CereggiiConstant_Type (commit) (failure)
• AtomicInt_Type (commit) (failure)

Both are failing in exactly the same way.

I haven't tried every single type, I suspect they would behave the same.

[ZeroIntensity]

Sorry, I don't know how to reproduce this. Trying to use CMake builds for locally installed Python versions is a PITA, and I wasn't able to get it working with setuptools. If you could come up with a more standalone reproducer, that would be useful.

Another possible case here is that this is memory corruption; something getting passed to PyType_Ready could be any arbitrary memory, and if that memory happens to have a NULL at the same offset as tp_name, then that would cause problems. I suggest running through valgrind to rule out that possibility.

[dpdani]

Understood, no problem.

Will try to make a minimal repro, or will confirm it's some bug with my code, as soon as I can.

[dpdani]

Hello there 👋

I can confirm it was a bug with my code. Thank you for your patience 🙏

[ZeroIntensity]

For future reference, what was the bug? It's helpful for us to know in case this issue comes up in the future :)

[dpdani]

Unfortunately, I couldn't really pin-point the problem: I fixed a number of bugs related to jumping the target Python version to 3.9 to 3.13.

Now I don't think it was related to any of those bugs, though.

While I was fixing stuff I switched the action for the free-threaded build from deadsnakes/action to astral-sh/setup-uv.
It appears the problem is actually still there if I switch back to the deadsnakes action:

• with deadsnakes (commit)
• with uv (commit)

I'm very confused at this point, I was thinking it was related to my code, but it looks like it's not.