[BUG]: build-wheels with coverage started failing Oct 29 with stack overflow #3330

Is this a duplicate?

• I confirmed there appear to be no duplicate issues for this bug and that I agree to the Code of Conduct

Type of Bug

Compile-time Error

Component

Infrastructure

Describe the bug

The Windows coverage workflow has failed in four consecutive runs at Build cuda.core wheel:

• Last passing: run 40794818147
• First failing: run 40980476988
• Investigated failure: run 41257298472
  Each failure stops immediately after reporting the installed cuda-bindings, before cuda-core Cythonization:

Using cuda-bindings 13.4.4.dev427+g01037b16d from ...
Building wheel for cuda-core (pyproject.toml) did not run successfully.
exit code: 3221225725
No available output.

Exit code 3221225725 (0xC00000FD) is Windows STATUS_STACK_OVERFLOW.

The first failure follows PR #3275, which replaced actions/setup-python with uv-managed python-build-standalone:

The stack reserves were verified by inspecting executable headers from official Python 3.14.9 and the exact standalone 3.14.10 archive selected by uv.
The runner image, MSVC version, Cython 3.2.9, setuptools, setuptools-scm, and relevant build-hook code were unchanged across this transition.
The likely failure point is the build hook’s import of the coverage-built cuda.bindings.driver. The workflow already runs Windows tests on an 8 MB stack, but that workaround does not cover the wheel-build subprocess.
Suspected cause: the smaller stack exposes an existing stack requirement during import of the coverage-built bindings.
Suggested confirmation: rerun the build hook with a larger stack while retaining the patched Python interpreter.
The stack overflow and distribution change are confirmed; their causal connection remains inferred pending a Windows rerun.

Proposed Fix:
Run _build_cuda_core() on a worker thread with an explicitly allocated 8 MiB stack inside the build backend. Wrapping pip itself would leave its build subprocess using the default stack.

For a diagnostic change, add these imports to [build_hooks.py (line 699)](/data/src/cuda-

python/cuda_core/build_hooks.py:699):
import threading
from concurrent.futures import ThreadPoolExecutor

Then replace build_wheel() with:

def build_wheel(wheel_directory, config_settings=None, metadata_directory=None):
    debug = config_settings.get("debug", False) if config_settings else False

    if sys.platform == "win32" and COMPILE_FOR_COVERAGE:
        previous_stack_size = threading.stack_size(8 * 1024 * 1024)
        try:
            with ThreadPoolExecutor(max_workers=1) as pool:
                config_key = pool.submit(_build_cuda_core, debug=debug).result()
        finally:
            threading.stack_size(previous_stack_size)
    else:
        config_key = _build_cuda_core(debug=debug)

    wheel_name = _build_meta.build_wheel(
        wheel_directory, config_settings, metadata_directory
    )
    record_build_config(config_key)
    return wheel_name

threading.stack_size() controls subsequently created threads. This puts the suspected bindings import on the larger stack, propagates Python exceptions through .result(), and restores the previous setting afterward.
The existing pip wheel command stays the same. A passing Windows coverage build with this change would strongly support the stack-size diagnosis.

How to Reproduce

Run coverage.yml build.

Expected behavior

It is able to build the wheel successfully.

Operating System

No response

nvidia-smi output

No response