You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[BUG]: VirtualMemoryResource leaks VMM handles after successful allocation and growth #2344
VirtualMemoryResource appears to keep CUDA VMM allocation handles alive after a successful allocation or growth operation.
The successful paths call cuMemCreate() and map the returned handle, but the transaction is committed without releasing that handle. When the Buffer is closed, deallocate() retains and releases another reference to the mapping; the original handle remains unreleased.
CUDA documents that the backing allocation is only freed after the mapping and all unreleased handles are gone. This means repeated allocate/close cycles can steadily consume GPU memory and eventually fail with CUDA_ERROR_OUT_OF_MEMORY.
How to reproduce
On a CUDA VMM-capable GPU, run this against current main:
On the affected path, GPU memory usage keeps increasing after buf.close() and the loop eventually reaches CUDA_ERROR_OUT_OF_MEMORY. Applying the proposed fix and running the same loop should keep usage near the post-close baseline.
The same lifecycle issue is present in the successful fast- and slow-path growth operations, where newly created and retained handles are committed without being released.
Expected behavior
Closing a Buffer should release the VMM allocation completely. Repeated allocate/close and grow/close cycles should not leak GPU memory or allocation handles.
Additional context
The proposed fix in PR #2235 releases newly created and retained handles before committing the transaction, while keeping release failures inside rollback handling.
Confirming this on an H100 with a CUDA 13.4 driver. Allocating and closing 64 buffers of 64 MiB each through VirtualMemoryResource leaves free device memory down by exactly the amount allocated:
With the creation reference released right after the mapping succeeds, the same probe reports retained_after_close=0MiB. Both grow paths have the same shape: the fast path never releases the new chunk's cuMemCreate reference, and the slow path additionally never releases the handle it retains with cuMemRetainAllocationHandle; #2235 covers all three sites. I filed #2882 for this before finding this issue and am closing it as a duplicate.
Activity
leofang commentedon Jul 15, 2026
Thanks for your report, @fallintoplace. I can reproduce. However, I think your fix has room for improvement. Let's move the discussion to your PR.
Andy-Jost commentedon Sep 16, 2026
Confirming this on an H100 with a CUDA 13.4 driver. Allocating and closing 64 buffers of 64 MiB each through
VirtualMemoryResourceleaves free device memory down by exactly the amount allocated:With the creation reference released right after the mapping succeeds, the same probe reports
retained_after_close=0MiB. Both grow paths have the same shape: the fast path never releases the new chunk'scuMemCreatereference, and the slow path additionally never releases the handle it retains withcuMemRetainAllocationHandle; #2235 covers all three sites. I filed #2882 for this before finding this issue and am closing it as a duplicate.