Skip to content

gh-132176: Fix crash on type() when tuple subclass passed as bases #132212

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

Merged
merged 4 commits into from
Apr 15, 2025

Conversation

sobolevn
Copy link
Member

@sobolevn sobolevn commented Apr 7, 2025

Co-authored-by: Victor Stinner <vstinner@python.org>
Copy link
Member

@vstinner vstinner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@sobolevn
Copy link
Member Author

Thank you, @vstinner for your help!

@sobolevn sobolevn added the needs backport to 3.13 bugs and security fixes label Apr 15, 2025
@sobolevn sobolevn merged commit b6c552f into python:main Apr 15, 2025
47 checks passed
@miss-islington-app
Copy link

Thanks @sobolevn for the PR 🌮🎉.. I'm working now to backport this PR to: 3.13.
🐍🍒⛏🤖

miss-islington pushed a commit to miss-islington/cpython that referenced this pull request Apr 15, 2025
…s `bases` (pythonGH-132212)

(cherry picked from commit b6c552f)

Co-authored-by: sobolevn <mail@sobolevn.me>
Co-authored-by: Victor Stinner <vstinner@python.org>
@bedevere-app
Copy link

bedevere-app bot commented Apr 15, 2025

GH-132548 is a backport of this pull request to the 3.13 branch.

@bedevere-app bedevere-app bot removed the needs backport to 3.13 bugs and security fixes label Apr 15, 2025
sobolevn added a commit that referenced this pull request Apr 15, 2025
…as `bases` (GH-132212) (#132548)

gh-132176: Fix crash on `type()` when `tuple` subclass passed as `bases` (GH-132212)
(cherry picked from commit b6c552f)

Co-authored-by: sobolevn <mail@sobolevn.me>
Co-authored-by: Victor Stinner <vstinner@python.org>
@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot aarch64 Fedora Stable LTO + PGO 3.x (tier-2) has failed when building commit b6c552f.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/#/builders/524/builds/7381) and take a look at the build logs.
  4. Check if the failure is related to this commit (b6c552f) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/#/builders/524/builds/7381

Summary of the results of the build (if available):

Click to see traceback logs
remote: Enumerating objects: 13, done.        
remote: Counting objects:   7% (1/13)        
remote: Counting objects:  15% (2/13)        
remote: Counting objects:  23% (3/13)        
remote: Counting objects:  30% (4/13)        
remote: Counting objects:  38% (5/13)        
remote: Counting objects:  46% (6/13)        
remote: Counting objects:  53% (7/13)        
remote: Counting objects:  61% (8/13)        
remote: Counting objects:  69% (9/13)        
remote: Counting objects:  76% (10/13)        
remote: Counting objects:  84% (11/13)        
remote: Counting objects:  92% (12/13)        
remote: Counting objects: 100% (13/13)        
remote: Counting objects: 100% (13/13), done.        
remote: Compressing objects:  20% (1/5)        
remote: Compressing objects:  40% (2/5)        
remote: Compressing objects:  60% (3/5)        
remote: Compressing objects:  80% (4/5)        
remote: Compressing objects: 100% (5/5)        
remote: Compressing objects: 100% (5/5), done.        
remote: Total 7 (delta 6), reused 3 (delta 2), pack-reused 0 (from 0)        
From https://github.com/python/cpython
 * branch                    main       -> FETCH_HEAD
Note: switching to 'b6c552f9e614bab4acf21584baed997f57e74114'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at b6c552f9e61 gh-132176: Fix crash on `type()` when `tuple` subclass passed as `bases` (#132212)
Switched to and reset branch 'main'

find: ‘build’: No such file or directory
find: ‘build’: No such file or directory
find: ‘build’: No such file or directory
find: ‘build’: No such file or directory
make[2]: [Makefile:3311: clean-retain-profile] Error 1 (ignored)
Python/ceval.c: In function ‘_PyEvalFramePushAndInit_Ex’:
Python/ceval.c:1852:38: warning: ‘stack_array’ may be used uninitialized [-Wmaybe-uninitialized]
 1852 |     _PyInterpreterFrame *new_frame = _PyEvalFramePushAndInit(
      |                                      ^~~~~~~~~~~~~~~~~~~~~~~~
 1853 |         tstate, func, locals,
      |         ~~~~~~~~~~~~~~~~~~~~~         
 1854 |         newargs, nargs, kwnames, previous
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 1855 |     );
      |     ~                                 
Python/ceval.c:1775:1: note: by argument 4 of type ‘const union _PyStackRef *’ to ‘_PyEvalFramePushAndInit’ declared here
 1775 | _PyEvalFramePushAndInit(PyThreadState *tstate, _PyStackRef func,
      | ^~~~~~~~~~~~~~~~~~~~~~~
Python/ceval.c:1821:17: note: ‘stack_array’ declared here
 1821 |     _PyStackRef stack_array[8];
      |                 ^~~~~~~~~~~
ar: unable to copy file 'libpython3.14.a'; reason: No space left on device
make[2]: *** [Makefile:1149: libpython3.14.a] Error 1
make[1]: *** [Makefile:981: profile-gen-stamp] Error 2
make: *** [Makefile:993: profile-run-stamp] Error 2

@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot AMD64 Windows11 Non-Debug 3.x (tier-1) has failed when building commit b6c552f.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/#/builders/914/builds/4825) and take a look at the build logs.
  4. Check if the failure is related to this commit (b6c552f) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/#/builders/914/builds/4825

Failed tests:

  • test_wmi

Failed subtests:

  • test_wmi_query_repeated - test.test_wmi.WmiTests.test_wmi_query_repeated

Summary of the results of the build (if available):

==

Click to see traceback logs
Traceback (most recent call last):
  File "b:\uildarea\3.x.ware-win11.nondebug\build\Lib\test\test_wmi.py", line 41, in test_wmi_query_repeated
    self.test_wmi_query_os_version()
    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^^
  File "b:\uildarea\3.x.ware-win11.nondebug\build\Lib\test\test_wmi.py", line 30, in test_wmi_query_os_version
    self.assertEqual(1, len(r))
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^
AssertionError: 1 != 2

@bedevere-bot
Copy link

⚠️⚠️⚠️ Buildbot failure ⚠️⚠️⚠️

Hi! The buildbot aarch64 Fedora Stable LTO 3.13 (tier-2) has failed when building commit 6d48194.

What do you need to do:

  1. Don't panic.
  2. Check the buildbot page in the devguide if you don't know what the buildbots are or how they work.
  3. Go to the page of the buildbot that failed (https://buildbot.python.org/#/builders/1399/builds/646) and take a look at the build logs.
  4. Check if the failure is related to this commit (6d48194) or if it is a false positive.
  5. If the failure is related to this commit, please, reflect that on the issue and make a new Pull Request with a fix.

You can take a look at the buildbot page here:

https://buildbot.python.org/#/builders/1399/builds/646

Summary of the results of the build (if available):

Click to see traceback logs
remote: Enumerating objects: 7, done.        
remote: Counting objects:  20% (1/5)        
remote: Counting objects:  40% (2/5)        
remote: Counting objects:  60% (3/5)        
remote: Counting objects:  80% (4/5)        
remote: Counting objects: 100% (5/5)        
remote: Counting objects: 100% (5/5), done.        
remote: Compressing objects:  50% (1/2)        
remote: Compressing objects: 100% (2/2)        
remote: Compressing objects: 100% (2/2), done.        
remote: Total 7 (delta 3), reused 3 (delta 3), pack-reused 2 (from 1)        
From https://github.com/python/cpython
 * branch                    3.13       -> FETCH_HEAD
Note: switching to '6d48194d9f14b7d6a5ee069a7bd269c124c17d59'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by switching back to a branch.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -c with the switch command. Example:

  git switch -c <new-branch-name>

Or undo this operation with:

  git switch -

Turn off this advice by setting config variable advice.detachedHead to false

HEAD is now at 6d48194d9f1 [3.13] gh-132176: Fix crash on `type()` when `tuple` subclass passed as `bases` (GH-132212) (#132548)
Switched to and reset branch '3.13'

In function ‘hashtable_key_from_2_strings’,
    inlined from ‘_extensions_cache_find_unlocked’ at Python/import.c:1264:17:
Python/import.c:1177:5: warning: ‘strncpy’ output truncated before terminating nul copying as many bytes from a string as its length [-Wstringop-truncation]
 1177 |     strncpy(key, str1_data, str1_len);
      |     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Python/import.c:1163:27: note: length computed here
 1163 |     Py_ssize_t str1_len = strlen(str1_data);
      |                           ^~~~~~~~~~~~~~~~~
ar: unable to copy file 'libpython3.13.a'; reason: No space left on device
make: *** [Makefile:1061: libpython3.13.a] Error 1

@vstinner
Copy link
Member

aarch64 Fedora Stable LTO + PGO 3.x and aarch64 Fedora Stable LTO 3.13 failed because their disk is full, see: #132553.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants