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
cuda.core: a fast-path VMM grow leaves its extension unfreeable #2887
_grow_allocation_fast_path maps a new chunk into a second, adjacent VA reservation and updates buf._size in place. The Buffer's deleter captured the original size when the buffer was created, so close() calls deallocate(ptr, original_size) and frees only the first reservation. The extension's reservation, mapping, and physical memory leak with no warning.
No deallocate(ptr, size) call can fix this: cuMemAddressFree frees a reservation only when ptr and size match exactly one reservation, so a range that spans two reservations cannot be freed in one call. The buffer needs to own each reservation and mapping it consists of.
Status
Today the fast path is unreachable (#2388 defect 2). #2237 and #2407 make it live and would expose this leak, so they should wait for this fix. The existing fast-path test mocks the driver and cannot catch it.
Update: I opened PR #2890 with the focused VMM deallocation-metadata fix and regression coverage. It is a draft so maintainers can review the C++ handle change and run CUDA validation.
Activity
aryanputta commentedon Sep 17, 2026
Update: I opened PR #2890 with the focused VMM deallocation-metadata fix and regression coverage. It is a draft so maintainers can review the C++ handle change and run CUDA validation.
fix(cuda.core): move VirtualMemoryResource onto the _rt handle layer (N…