coverage: repair the Windows coverage wheels - #2508
Open
rluo8 wants to merge 2 commits into
Open
Conversation
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 <ruluo@nvidia.com>
Contributor
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
rluo8
marked this pull request as ready for review
August 5, 2026 06:09
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
The Windows coverage of
CI: Coveragehas not collected cuda.core data: the step dies in seconds with exit 139 and no pytest output. Two separate causes, both in this workflow's wheel build.1. The crash
Cause. A plain
pip wheeldoes not read[tool.cibuildwheel], so thedelvewheel repairevery other Windows build runs never happened here, and the.pydfiles load whateverMSVCP140.dllthe test machine has — on this runner 14.00.24215.1, from 2015._resource_handles.pydis built by MSVC 14.44 and imports_Mtx_lock/_Mtx_unlockbut never_Mtx_init_in_situ, becausestd::mutexhas had a constexpr constructor since VS 2022 17.10. The old runtime still dereferences that uninitialised handle on the first lock, which_stream.pyxtakes duringimport cuda.core:It is the only extension module in either package that locks a mutex, which is why
cuda.bindingsandcuda.pathfinderhave always passed on the same machine and why the PyPI wheels are unaffected.The fix is to repair these wheels too, with the same flags cibuildwheel uses: 14.44 is vendored into
cuda_core.libsand the import tables are rewritten to match, so the process no longer depends on what the test machine carries.2. The build failure
Cause.
PIP_PRE, needed so pip sees the.devNcuda-bindingswheel built one step earlier, also admits PyPI's pre-releases:13.4.0b1(published 2026-07-29) outranks it, and itscydriver.pxdcomes from CTK 13.4 headers whereCUmemLocationhas alocalizedfield, which the 13.3.0 mini-CTK used here does not. Cython generates a struct converter over every field, so the build fails witherror C2039— every night since, most recently run 30964133960.The fix is to constrain
cuda-bindingsto the version just built, which keeps whatPIP_PREis here for — compilingcuda.coreagainst the same bindings this job then installs and measures — and drops what it lets in.