Skip to content

Create the CUDA stream pool lazily instead of from a static initializer - #34

Open
seyfal wants to merge 1 commit into
CAPS-UMU:mainfrom
seyfal:fix/lazy-stream-pool-init
Open

seyfal wants to merge 1 commit into
CAPS-UMU:mainfrom
seyfal:fix/lazy-stream-pool-init

Conversation

@seyfal

@seyfal seyfal commented Sep 5, 2026

Copy link
Copy Markdown
Contributor

initPool() runs from a static initializer in src/CudaUtils.cu, so the process's first CUDA runtime calls (cudaGetDeviceCount, cudaSetDevice, cudaStreamCreateWithFlags) happen before main(). When one of those calls fails, the CUDA runtime stays in the error state, stream_pool is never filled, and the first Stream::init indexes assigner_idx with a garbage device id and segfaults. We hit this on a 2x H200 machine with one GPU in a degraded state (invalid device ordinal); on a healthy host nothing is visible.

This change builds the pool on first use, from Stream::init, through a function-local static (still one-time and thread-safe). No API change, and no change in behaviour on healthy hosts.

Tested on v2.1.3 (786c760) with CUDA 13.0 / driver 580 on H200: the degraded host went from segfault to running, and our bootstrapped CKKS workloads have been running on this patch since 2026-08-31. The commit also applies cleanly on OpenFHECompatTests.

Fable 5.1 on behalf of Seyfal

initPool() ran from a static initializer, so the first CUDA runtime calls of
the process happened before main(). On a host where such an early call fails
(here: one degraded GPU, cudaGetDeviceCount -> "invalid device ordinal") the
runtime stays in the error state, stream_pool is never filled, and
Stream::init later indexes assigner_idx with a garbage device id and
segfaults. Build the pool on first use from Stream::init instead. No change
in behaviour on healthy hosts.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant