From b2cb6ff250c4f349ca86a0cab22c5f1a8d779787 Mon Sep 17 00:00:00 2001 From: Rui Luo Date: Wed, 5 Aug 2026 12:55:33 +0800 Subject: [PATCH] coverage: repair the Windows coverage wheels Windows coverage has not collected a test since 2026-03-17. The job builds its wheels with a plain `pip wheel`, which never reads [tool.cibuildwheel], so the delvewheel repair every other Windows build performs never ran here. Those wheels import a bare "MSVCP140.dll" and resolve it against whatever the test machine has in System32, which on the coverage runner is 14.00.24215.1, built in 2015. _resource_handles.pyd is compiled by MSVC 14.44 and imports exactly _Mtx_lock and _Mtx_unlock from that DLL -- never _Mtx_init_in_situ, because std::mutex has had a constexpr constructor since VS 2022 17.10. The 2015 runtime still expects that initialisation and dereferences a null handle on the first lock, which _stream.pyx takes while cuda.core is still importing. It is the only extension module in either package that locks a mutex, which is why cuda.bindings and cuda.pathfinder have always passed on the same machine. Repairing the wheels vendors msvcp140 14.44 into cuda_core.libs and rewrites the import tables to match, so the process no longer depends on what the test machine carries. Verified on the coverage runner: 18 failed, 2929 passed, 918 skipped in 346s, against three to seven seconds of dying beforehand, and the first Windows coverage data since March. The same commit pins cuda-bindings to the wheel built one step earlier. PIP_PRE is set so pip will consider that wheel at all -- it carries a .devN version -- but it also admits PyPI's pre-releases, and cuda-bindings 13.4.0b1, published 2026-07-29, outranks the local build. Its cydriver.pxd comes from CTK 13.4 headers where CUmemLocation has a `localized` field, while cuda.core compiles against the 13.3.0 mini-CTK where it does not, so the build has been failing on `error C2039` ever since. Signed-off-by: Rui Luo --- .github/workflows/coverage.yml | 21 +++++++++++++++++++++ 1 file changed, 21 insertions(+) diff --git a/.github/workflows/coverage.yml b/.github/workflows/coverage.yml index e354a204d02..ecc90674c78 100644 --- a/.github/workflows/coverage.yml +++ b/.github/workflows/coverage.yml @@ -235,13 +235,34 @@ jobs: cd cuda_bindings ../.venv/Scripts/pip wheel -v --no-deps . -w ../wheels/ + # Pin cuda-bindings to the wheel built above; PIP_PRE, which is what makes + # that .devN wheel visible, would otherwise let a PyPI pre-release win. - name: Build cuda.core wheel run: | export PIP_FIND_LINKS="$(pwd)/wheels" export PIP_PRE=1 + bindings_whl="$(ls ./wheels/cuda_bindings-*.whl | head -1)" + bindings_ver="$(basename "$bindings_whl" | cut -d- -f2)" + echo "cuda-bindings==${bindings_ver%%+*}" > "$GITHUB_WORKSPACE/constraints.txt" + cat "$GITHUB_WORKSPACE/constraints.txt" + export PIP_CONSTRAINT="$GITHUB_WORKSPACE/constraints.txt" cd cuda_core ../.venv/Scripts/pip wheel -v --no-deps . -w ../wheels/ + # Vendor the DLLs these wheels were built against, the way cibuildwheel + # does for every other Windows build. --namespace-pkg is needed because + # `cuda` is a namespace package. + - name: Repair the Windows wheels + run: | + .venv/Scripts/pip install delvewheel + mkdir -p wheels-repaired + for whl in ./wheels/cuda_bindings-*.whl ./wheels/cuda_core-*.whl; do + .venv/Scripts/delvewheel repair --namespace-pkg cuda \ + --exclude "torch_cpu.dll;torch_python.dll" \ + -w ./wheels-repaired "$whl" + done + mv -f ./wheels-repaired/*.whl ./wheels/ + - name: List wheel artifacts run: | echo "=== Windows wheel artifacts ==="