kvcache-ai/Mooncake

Fork 0

mirror of https://github.com/kvcache-ai/Mooncake.git synced 2026-11-05 01:17:55 +00:00

[GH-ISSUE #3153] [Bug]: V0. 3.12.post1 Transfer Engine does not support overlapped memory region #808

New issue

Open

opened 2026-10-29 21:19:46 +00:00 by bsakaguchi · 4 comments

bsakaguchi commented

2026-10-29 21:19:46 +00:00

Owner

Originally created by @CSEEduanyu on GitHub (Jul 28, 2026).
Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/3153

Bug Report

transfer_engine_impl.cpp:787] Transfer Engine does not support overlapped memory region

When I upgraded to version V0.3.12.post1, this error appeared

Before submitting...

Ensure you searched for relevant issues and read the [documentation]

Originally created by @CSEEduanyu on GitHub (Jul 28, 2026). Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/3153 ### Bug Report transfer_engine_impl.cpp:787] Transfer Engine does not support overlapped memory region When I upgraded to version V0.3.12.post1, this error appeared ### Before submitting... - [ ] Ensure you searched for relevant issues and read the [documentation]

bsakaguchi added the

stale

bug

labels

2026-10-29 21:19:46 +00:00

bsakaguchi commented

2026-10-29 21:19:47 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Jul 28, 2026):

Thanks for opening this issue, @CSEEduanyu!

Field	Value
Issue	#3153
GitHub user ID	`44152509`
Reporter	@CSEEduanyu

A maintainer will triage this when possible. To help us respond faster, please include:

Mooncake version or commit SHA
Environment (OS, CUDA/driver, RDMA stack if relevant)
Steps to reproduce and expected vs. actual behavior

Useful links: Documentation · Contributing guide

This message was posted automatically by the issue bot.

@github-actions[bot] commented on GitHub (Jul 28, 2026): Thanks for opening this issue, @CSEEduanyu! | Field | Value | |-------|-------| | **Issue** | #3153 | | **GitHub user ID** | `44152509` | | **Reporter** | @CSEEduanyu | A maintainer will triage this when possible. To help us respond faster, please include: - Mooncake version or commit SHA - Environment (OS, CUDA/driver, RDMA stack if relevant) - Steps to reproduce and expected vs. actual behavior Useful links: [Documentation](https://kvcache-ai.github.io/Mooncake/) · [Contributing guide](https://github.com/kvcache-ai/Mooncake/blob/main/CONTRIBUTING.md) > This message was posted automatically by the issue bot.

bsakaguchi commented

2026-10-29 21:19:47 +00:00

Author

Owner

@he-yufeng commented on GitHub (Jul 28, 2026):

This error is new in the 0.3.12 line: #2869/#2870 added an engine-level reservation that rejects any memory region overlapping an already-registered (or in-flight-registering) one, and the rejection also fires when the second registration is byte-identical to the first. Two quite different situations land on the same message, so it would help to know which one you're hitting:

Your app (or a connector above it) registers the same buffer twice, e.g. an init path plus a reload/reconnect, or two components sharing one allocation. That used to go through on older versions and now returns ERR_ADDRESS_OVERLAPPED even though nothing actually overlaps.
Two genuinely different regions overlap in address space, which the new check is meant to catch.

If it's case 1, that's a compatibility question for the maintainers: should an exact (addr, length) re-registration be an idempotent no-op while true overlaps stay rejected? The current tests pin the in-flight duplicate rejection but say nothing about sequential idempotency, so the contract was tightened silently by the reservation, probably not deliberately. A register call pattern (or a minimal repro) from you would settle which fix belongs here.

@he-yufeng commented on GitHub (Jul 28, 2026): This error is new in the 0.3.12 line: #2869/#2870 added an engine-level reservation that rejects any memory region overlapping an already-registered (or in-flight-registering) one, and the rejection also fires when the second registration is byte-identical to the first. Two quite different situations land on the same message, so it would help to know which one you're hitting: 1. Your app (or a connector above it) registers the same buffer twice, e.g. an init path plus a reload/reconnect, or two components sharing one allocation. That used to go through on older versions and now returns ERR_ADDRESS_OVERLAPPED even though nothing actually overlaps. 2. Two genuinely different regions overlap in address space, which the new check is meant to catch. If it's case 1, that's a compatibility question for the maintainers: should an exact (addr, length) re-registration be an idempotent no-op while true overlaps stay rejected? The current tests pin the in-flight duplicate rejection but say nothing about sequential idempotency, so the contract was tightened silently by the reservation, probably not deliberately. A register call pattern (or a minimal repro) from you would settle which fix belongs here.

bsakaguchi commented

2026-10-29 21:19:47 +00:00

Author

Owner

@alogfans commented on GitHub (Jul 29, 2026):

The above PR is expected to fix case 1.

@alogfans commented on GitHub (Jul 29, 2026): The above PR is expected to fix case 1.

bsakaguchi commented

2026-10-29 21:19:47 +00:00

Author

Owner

@github-actions[bot] commented on GitHub (Oct 27, 2026):

This issue has had no activity for 90 days and will be closed in 7 days if there is no further activity. Please comment or react if it should stay open.

@github-actions[bot] commented on GitHub (Oct 27, 2026): This issue has had no activity for 90 days and will be closed in 7 days if there is no further activity. Please comment or react if it should stay open.

bsakaguchi referenced this issue

2026-10-29 21:30:44 +00:00

[PR #808] [MERGED] feat(build): add CI-specific build option with --ci-build flag #1836