❯ ./python -m test test_descr -m test_slots -R 3:3
0:00:00 load avg: 0.26 Run tests sequentially
0:00:00 load avg: 0.26 [1/1] test_descr
beginning 6 repetitions
123456
test test_descr failed -- Traceback (most recent call last):
  File "/home/pablogsal/github/cpython/Lib/test/test_descr.py", line 1201, in test_slots
    c.abc = 5
AttributeError: 'C' object has no attribute 'abc'

test_descr failed

== Tests result: FAILURE ==

1 test failed:
test_descr

Total duration: 72 ms
Tests result: FAILURE

Bisecting points at:

commit ee48c7d
Author: Dino Viehland <dinoviehland@fb.com>
Date: Sat Mar 20 12:12:05 2021 -0700

bpo-43452: Micro-optimizations to PyType_Lookup (GH-24804)

The common case going through _PyType_Lookup is to have a cache hit. There are some small tweaks that can make this a little cheaper:

* The name field identity is used for a cache hit and is kept alive by the cache. So there's no need to read the hash code o the name - instead, the address can be used as the hash.

*  There's no need to check if the name is cachable on the lookup either, it probably is, and if it is, it'll be in the cache.

*  If we clear the version tag when invalidating a type then we don't actually need to check for a valid version tag bit.

Dino, could you take a look?

Looking!

Seems that the problem is removing the check:

if (MCACHE_CACHEABLE_NAME(name) &&
    _PyType_HasFeature(type, Py_TPFLAGS_VALID_VERSION_TAG)) {

It's probably worth having an assert that the version tag is valid, that'll make it easier to see what's going wrong in the cache hit case. We should have the version tag being 0 now when it's not valid. I may not be able to debug it anymore tonight, but if no will look tomorrow.

And it looks like we have an entry with a 0 version, but with a valid name:

(type_cache_entry) $3 = {
version = 0
name = 0x0000000100ec44f0
value = NULL
}

I think I have it, we still neet to validate that the version tag is correct. Can you take a look at #25032 ?

I think the issue here is that in assign_version_tag there's this code:

    if (type->tp_version_tag == 0) {
        // Wrap-around or just starting Python - clear the whole cache
        type_cache_clear(cache, 1);
        return 1;
    }

the return 1 is incorrect, it should be return 0 as a valid version tag hasn't been assigned.

Yup, that makes sense. Let me update the PR

New changeset 11b85ab by Pablo Galindo in branch 'master':
bpo-43636: Validate the version tag in _PyType_Lookup (GH-25032)
11b85ab

Is _PyType_Lookup() still faster after the fix? The optimization is mentioned at:
https://docs.python.org/dev/whatsnew/3.10.html#optimizations

@vstinner - The fix doesn't change the behavior of _PyType_Lookup and instead just fixes a previous unrelated bug. The condition will typically ever be hit once (at startup) as it's very unlikely that versions will wrap, so there should be no performance difference after the fix.