Skip to content

Leak test of test_descr fails Base2 != Base #133122

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
nascheme opened this issue Apr 29, 2025 · 1 comment
Open

Leak test of test_descr fails Base2 != Base #133122

nascheme opened this issue Apr 29, 2025 · 1 comment
Labels
3.13 bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error

Comments

@nascheme
Copy link
Member

nascheme commented Apr 29, 2025

Bug report

Bug description:

This seems to be caused by GH-133114.

Command to re-produce:

./python -m test -R 3:3 -j12 test_descr

The failure output:

FAIL: test_type_lookup_mro_reference (test.test_descr.MiscTests.test_type_lookup_mro_reference)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/buildbot/buildarea/3.13.cstratak-RHEL8-x86_64.refleak/build/Lib/test/test_descr.py", line 5181, in test_type_lookup_mro_reference
    self.assertEqual(X.mykey, 'from Base')
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^
AssertionError: 'from Base2' != 'from Base'
- from Base2
?          -
+ from Base
----------------------------------------------------------------------
Ran 156 tests in 0.829s
FAILED (failures=1, skipped=1, expected failures=2)
test test_descr failed

This appears to be another bug in the type lookup (MRO) cache.

CPython versions tested on:

3.13

Operating systems tested on:

Linux

Linked PRs

@nascheme nascheme added the type-bug An unexpected behavior, bug, or error label Apr 29, 2025
@nascheme
Copy link
Member Author

Some progress on debugging this. It seems to be an issue with the specialize. In specialize.c, we have analyze_descriptor() calling _PyType_Lookup() and that's causing the tricky __eq__ to be executed before the real lookup happens. So the __bases__ gets replaced before the unit test expects. At least, that's my theory.

I'm not sure if we consider the bytecode specializer buggy for doing this or the unit test buggy for expecting it to work exactly as is being test. Perhaps you can not expect deterministic results when changing __bases__ while doing a type lookup.

nascheme added a commit that referenced this issue Apr 29, 2025
Change the unit test case to use `getattr()` so that we avoid the
bytecode specializer optimizing the access.  The specializer will call
the `__eq__` method before the unit test expects, causing it to fail.

In the 3.14 branch (gh-128164) the test is changed in a different way
to avoid the same issue.
@picnixz picnixz added 3.13 bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) labels Apr 30, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3.13 bugs and security fixes interpreter-core (Objects, Python, Grammar, and Parser dirs) type-bug An unexpected behavior, bug, or error
Projects
None yet
Development

No branches or pull requests

2 participants