PyTorch + CUDA-Q: invalid resource handle when system and wheel libcudart both load

Required prerequisites

• Consult the security policy. If reporting a security vulnerability, do not report the bug using this form. Use the process described in the policy to report the issue.
• Make sure you've read the documentation. Your issue may be addressed there.
• Search the issue tracker to verify that this hasn't already been reported. +1 or comment there if it has.
• If possible, make a PR with a failing test to give us a starting point to work on!

Describe the bug

In some Python environments, CUDA-Q (linked against the system CUDA runtime) and PyTorch from pip (which ships its own CUDA libraries under site-packages/nvidia/...) can load two different libcudart shared objects in the same process. The dynamic linker treats them as separate libraries (different paths / inodes), so you effectively get two CUDA runtimes. CUDA handles, contexts, streams, and memory allocated in one runtime are not valid in the other, which surfaces as errors such as cudaErrorInvalidResourceHandle—often wrapped as torch.AcceleratorError when moving tensors or models to GPU (e.g. GPT-2 .to("cuda")). This is a process-level dynamic linking / packaging interaction between CUDA-Q and PyTorch’s bundled CUDA stack; it is not necessarily a logic bug inside the GQE or solver code paths, though those tests are where we hit GPU + torch together.

What we observed: Inspection of /proc/self/maps showed multiple distinct libcudart mappings, for example:
• System: /usr/local/cuda-13.0/targets/x86_64-linux/lib/...
• Wheel: /usr/local/lib/python3.12/dist-packages/nvidia/cu13/lib/...

Failed CI: https://github.com/NVIDIA/cudaqx/actions/runs/23257071794/job/67614984596?pr=467

Steps to reproduce the bug

Tier 1 — Dual-runtime diagnostic (Linux, no pytest)

1. On a machine with an NVIDIA GPU and a driver compatible with the CUDA generation you use (e.g. CUDA 13 or 12.6, matching
   your wheels).
2. Install the same stack as CI (CUDA-Q + GPU PyTorch + test deps), or use the Docker image below.
3. Run the standalone script below (default: imports torch so PyTorch’s CUDA stack loads). Optional: export
   CUDA_LAUNCH_BLOCKING=1 when debugging.
4. Expected for a healthy single-runtime setup: exactly one distinct libcudart.so path in the process. Problem signal: two or
   more distinct paths → dual-runtime risk.

Tier 2 — Same environment, minimal GPU + torch
After Tier 1 shows multiple libcudart paths, a minimal check is: import torch then allocate a small tensor on CUDA (e.g.
torch.zeros(1, device="cuda")). If Tier 1 is red, failures here are consistent with cross-runtime invalid handles.

Standalone script (maps-based dual-runtime check)

from __future__ import annotations

import argparse
import os
import sys


def libcudart_paths_from_maps() -> list[str] | None:
    """Distinct paths in /proc/self/maps whose basename contains libcudart.so."""
    maps_file = "/proc/self/maps"
    if not os.path.exists(maps_file):
        return None
    seen: set[str] = set()
    with open(maps_file) as f:
        for line in f:
            parts = line.split()
            if len(parts) < 6:
                continue
            path = parts[-1]
            if "libcudart.so" in path and path not in seen:
                seen.add(path)
    return sorted(seen)


def main() -> int:
    p = argparse.ArgumentParser(
        description="Report loaded libcudart.so paths (dual-runtime diagnostic)."
    )
    p.add_argument(
        "--no-import-torch",
        action="store_true",
        help="Skip torch import (default: import torch to load PyTorch's CUDA stack).",
    )
    args = p.parse_args()
    import_torch = not args.no_import_torch

    if import_torch:
        try:
            import torch  # noqa: F401
        except ImportError:
            print("torch is not installed; re-run with --no-import-torch.", file=sys.stderr)
            return 2

    paths = libcudart_paths_from_maps()
    if paths is None:
        print("/proc/self/maps not available (need Linux).", file=sys.stderr)
        return 2

    print("Loaded libcudart.so paths in this process:")
    for path in paths:
        print(f"  {path}")

    n = len(paths)
    if n == 0:
        print("\nNo libcudart.so mappings found (unexpected if using CUDA).")
        return 0
    if n == 1:
        print("\nOK: single libcudart mapping.")
        return 0

    print(
        f"\nDUAL-RUNTIME RISK: {n} distinct libcudart.so paths are mapped.",
        file=sys.stderr,
    )
    print(
        "CUDA objects from one copy may be invalid in the other "
        "(e.g. cudaErrorInvalidResourceHandle, torch.AcceleratorError).",
        file=sys.stderr,
    )
    return 1


if __name__ == "__main__":
    sys.exit(main())

Expected behavior

• One CUDA runtime per process. Only one libcudart should load; CUDA objects (contexts, streams, memory) from CUDA-Q,
PyTorch, and other CUDA code should stay valid in the same process.
• GQE + GPU PyTorch, with a matching driver and a single, consistent CUDA stack (CUDA-Q, PyTorch, and solvers built for the same CUDA generation, no conflicting runtimes), test_solvers_gqe_basic and similar flows should finish without CUDA errors.

Is this a regression? If it is, put the last known working version (or commit) here.

Not a regression

Environment

• CUDA-Q version: https://github.com/NVIDIA/cuda-quantum d84568366c3f9e9a33b3829ff43fb794b3a703ab
• Python version: 3.12.3
• C++ compiler: 13.3.0
• Operating system: Ubuntu 13.3.0-6ubuntu2~24.04.1

Suggestions

No response

Start by running the standalone maps-based diagnostic on Linux, then inspect the linked CI job and the test_solvers_gqe_basic flow. Compare the libcudart paths loaded with and without torch; done means one runtime mapping remains and the GQE GPU/PyTorch tests complete without invalid-resource-handle errors.