deepseek-ai/DeepEP
1
0
Fork 0
mirror of https://github.com/deepseek-ai/DeepEP.git synced 2026-11-05 00:47:32 +00:00
Code Issues 308 Projects Packages Wiki Activity

[GH-ISSUE #497] [Question] Is there undefined behavior between the calls to cudaFree and cudaIpcCloseMemHandle? #322

New issue
Open
opened 2026-10-26 09:58:35 +00:00 by bsakaguchi · 1 comment
bsakaguchi commented 2026-10-26 09:58:35 +00:00
Owner
Copy link

Originally created by @hexclover on GitHub (Nov 18, 2025).
Original GitHub issue: https://github.com/deepseek-ai/DeepEP/issues/497

In Buffer::destroy, each rank first closes the 7 external memory handles, then cudaFrees the local buffer.

However, the docs for cudaIpcOpenMemHandle says it is undefined behavior to cudaFree the exported memory region before the call to cudaIpcCloseMemHandle.

So in an extreme situation (actually I think this may be common) it is possible for rank 2 to close the handle exported from rank 1 long after rank 1 has freed that buffer. This should be technically considered undefined behavior, although I haven't been able to construct a test that exhibits clearly erroneous behavior, e. g. crashes.

Basically I am wondering about the robustness of this code: is it UB? Does it just happen to work? Or it is guaranteed to work given the current CUDA implementations?

Originally created by @hexclover on GitHub (Nov 18, 2025). Original GitHub issue: https://github.com/deepseek-ai/DeepEP/issues/497 In `Buffer::destroy`, each rank first closes the 7 external memory handles, then `cudaFree`s the local buffer. However, the docs for `cudaIpcOpenMemHandle` says it is undefined behavior to `cudaFree` the *exported memory region* before the call to `cudaIpcCloseMemHandle`. So in an extreme situation (actually I think this may be common) it is possible for rank 2 to close the handle exported from rank 1 long after rank 1 has freed that buffer. This should be technically considered undefined behavior, although I haven't been able to construct a test that exhibits clearly erroneous behavior, e. g. crashes. Basically I am wondering about the robustness of this code: is it UB? Does it just happen to work? Or it is guaranteed to work given the current CUDA implementations?
bsakaguchi commented 2026-10-26 09:58:36 +00:00
Author
Owner
Copy link

@alpha-baby commented on GitHub (Dec 18, 2025):

maybe you are right!

we should add intranode::barrier between cudaIpcCloseMemHandle and cudaFree

<!-- gh-comment-id:3668089538 --> @alpha-baby commented on GitHub (Dec 18, 2025): maybe you are right! we should add `intranode::barrier` between `cudaIpcCloseMemHandle` and `cudaFree`
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
hybrid-ep
chore/remove-clang-format-yapf
v2.5
nvDev
try-fix-cu128
mori-ep
antgroup-opt
compat-old-torch
add-linter
eager-rdma
v1.2.1
Labels
Clear labels   
pull-request
Mirrored from GitHub Pull Request

No labels
pull-request
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
deepseek-ai/DeepEP#322
No description provided.