ITADN

Resolve PyPy 7.3.22 `PyType_Ready` import failure in PyPy 3.11 CI on macOS and Windows

#6049Openrwgk 创建于 2026-05-02
triage
R
rwgkcommented
The macOS and Windows PyPy 3.11 CI jobs started failing on current `master`, while the same jobs were still green in PR #6036, which is the last known full CI run we checked. The most important observation from the logs is that: - the last known working macOS/Windows PyPy 3.11 jobs used `PyPy 7.3.21 (Py 3.11.15)` - the current failing macOS/Windows PyPy 3.11 jobs use `PyPy 7.3.22 (Py 3.11.15)` - Ubuntu PyPy 3.11 stayed on `PyPy 7.3.21 (Py 3.11.15)` and still passed That strongly suggests either: 1. a regression in PyPy `7.3.22`, or 2. a pybind11 compatibility issue that is exposed by PyPy `7.3.22` As an immediate mitigation, we should pin the macOS and Windows PyPy 3.11 CI jobs to `pypy-3.11-v7.3.21`. ## Last known working CI PR #6036 - macOS PyPy 3.11 success: - https://github.com/pybind/pybind11/actions/runs/24612330326/job/71968766480?pr=6036 - Windows PyPy 3.11 success: - https://github.com/pybind/pybind11/actions/runs/24612330326/job/71968766475?pr=6036 ## Current failing CI PR #5850 (`master_with_empty_commit`, rebased on current `master`) - macOS PyPy 3.11 failure: - https://github.com/pybind/pybind11/actions/runs/25258404339/job/74063820293?pr=5850 - Windows PyPy 3.11 failure: - https://github.com/pybind/pybind11/actions/runs/25258404339/job/74063820280?pr=5850 ## Ubuntu observation Ubuntu PyPy 3.11 did not reproduce the failure in the runs we checked, but the logs show that it was still using `PyPy 7.3.21`, so this is not evidence that `7.3.22` is fine on Ubuntu. - PR #6036 Ubuntu PyPy 3.11 success: - https://github.com/pybind/pybind11/actions/runs/24612330326/job/71968766459?pr=6036 - PR #5850 Ubuntu PyPy 3.11 success: - https://github.com/pybind/pybind11/actions/runs/25258404339/job/74063820431?pr=5850 Relevant log observations: - PR #6036 macOS success used `PyPy 7.3.21 (Py 3.11.15)` - PR #6036 Windows success used `PyPy 7.3.21 (Py 3.11.15)` - PR #5850 Ubuntu success used `PyPy 7.3.21 (Py 3.11.15)` - PR #5850 macOS failure used `PyPy 7.3.22 (Py 3.11.15)` - PR #5850 Windows failure used `PyPy 7.3.22 (Py 3.11.15)` So the current data is consistent with: - `7.3.21`: known good on macOS, Windows, Ubuntu - `7.3.22`: known bad on macOS, Windows - `7.3.22` on Ubuntu: not yet tested / not established from these runs ## Error details from the failing logs The macOS and Windows failures are effectively identical. In both cases, `pytest` fails immediately while importing `pybind11_tests` from `tests/conftest.py`. macOS: ```text Traceback (most recent call last): File "/Users/runner/work/pybind11/pybind11/tests/conftest.py", line 26, in <module> import pybind11_tests ImportError: D: PyType_Ready failed: TypeError: instance layout conflicts in multiple inheritance ImportError while loading conftest '/Users/runner/work/pybind11/pybind11/tests/conftest.py'. E ImportError: D: PyType_Ready failed: TypeError: instance layout conflicts in multiple inheritance FAILED: [code=4] tests/CMakeFiles/pytest ``` Windows: ```text Traceback (most recent call last): File "D:\a\pybind11\pybind11\tests\conftest.py", line 26, in <module> import pybind11_tests ImportError: D: PyType_Ready failed: TypeError: instance layout conflicts in multiple inheritance ImportError while loading conftest 'D:\a\pybind11\pybind11\tests\conftest.py'. E ImportError: D: PyType_Ready failed: TypeError: instance layout conflicts in multiple inheritance ``` ## Proposed action - Pin only the macOS and Windows PyPy 3.11 jobs to `7.3.21` for now. - Leave Ubuntu unpinned unless it also starts failing. - Open a follow-up investigation into what changed between PyPy `7.3.21` and `7.3.22`, or which pybind11 type registration/import path is now triggering: ```text PyType_Ready failed: TypeError: instance layout conflicts in multiple inheritance ```
0 条评论