[BUG]: VirtualMemoryResource: four pre-existing defects (grow-rollback access loss, dead fast path, finalizer warnings, handle_type docstring)
@aryanputta arbeitet bereits daran.
Seit 23.7.2026.
- Vorherrschende Sprache
- Cython
- Sterne
- 3.4k
- Forks
- 329
- Ø Merge
- 1 T. 21 Std.
- Gemergte PRs (30 T.)
- 113
Beschreibung
Component
cuda.core
What happened?
Four pre-existing defects in VirtualMemoryResource, all found while verifying #2235 (verification details in https://github.com/NVIDIA/cuda-python/pull/2235#pullrequestreview-4728931983); none are introduced by that PR.
-
Rollback of a failed grow loses access grants — if
modify_allocation()fails after the old range has been remapped (slow path), the_remap_oldrollback restores the mapping at the original address but never re-applies the access descriptors, so the rolled-back buffer faults on its next access untilcuMemSetAccessis re-run. Reproduced onmainby forcingcuMemSetAccessto fail during a grow. Likely fix:_remap_oldshould re-apply the resource's access descriptors to the old range (best-effort, matching the remap itself). -
The grow fast path is dead code — this check compares a
CUdeviceptragainst a plainint, andCUdeviceptr(x) == xis alwaysFalse, somodify_allocation()always takes the slow path (full re-reserve + remap, base pointer changes) even when the driver granted the exact contiguous extension address. Fix: compareint(new_ptr). -
Warning spam after every slow-path grow — the slow path calls
buf._clear()so the old buffer's destructor won't double-free, but the destructor still callsdeallocate(), emittingWarning: mr.deallocate() failed during Buffer destruction: CUDA_ERROR_INVALID_VALUEat GC after each grow. (Adjacent to the existing TODO referencing #2049.) -
handle_typedocstring is wrong — the docstring claims posix_fd is "required for cuMemRetainAllocationHandle"; retain works onhandle_type=Noneallocations (verified on driver r595) and the driver documentation has no such restriction.
-- Leo's bot
Beitragsleitfaden
Erste Schritte
- Lies das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreib ins Issue, dass du es übernimmst — das erspart doppelte Arbeit.
- Forke das Repository und arbeite in einem Branch.
- Öffne einen Pull Request, der die Issue-Nummer nennt.
Bewertung
Dieses Issue wurde noch nicht bewertet.