mirror of
https://github.com/kvcache-ai/Mooncake.git
synced 2026-11-05 01:17:55 +00:00
[GH-ISSUE #4504] [Bug]: Ascend NPU build - loading mooncake.store aborts the process at exit (heap corruption -> SIGABRT) #1146
Labels
No labels
ascend
auto-closed
bug
bug
CI/Build
Common
documentation
enhancement
feature request
good first issue
help wanted
high priority
MetaX
nightly-failure
pull-request
PyTorch Backend
question
RFC
Roadmap
stale
Store
Tests
Transfer Engine
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
kvcache-ai/Mooncake#1146
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @brandneway on GitHub (Oct 8, 2026).
Original GitHub issue: https://github.com/kvcache-ai/Mooncake/issues/4504
Describe the bug
On the Ascend NPU build, merely loading the Python extension
mooncake.store(ormooncake.engine) makes any process abort during interpreter shutdown, even though nothing else is done with Mooncake. glibc reports a corrupted heap block and raises SIGABRT, so the process exits with a non-zero status.This is not about using Mooncake: the failure fires in processes that only import it and then exit normally.
Environment
mooncake-transfer-engine-npu0.3.11.post1 (the wheel reports itself as "Python binding of a Mooncake library using pybind11 (Ascend NPU version)")/usr/local/Ascend/cann-9.1.0)Reproduction
mooncake.enginebehaves identically. Two refinements that narrow it down:Backtrace
freeis called from a CANN finalizer inlibascend_trace.soduring_dl_fini; the block it is releasing was already corrupt by then.What we ruled out
PYTHONMALLOC=debugmallocheapctypes.CDLL(store.so)with no Python code runningctypes.CDLL()onlibcann_hixl.so,libllm_datadist.so,libascend_trace.soindividuallyimport torch_npu(also mapslibascend_trace.so)os._exit(0)ldd store.soshows it links ~34 CANN libraries, among themlibcann_hixl.so,libllm_datadist.so,ascend_transport.so(the latter ships inside the mooncake package itself).What we could not determine
We did not identify which code writes the corrupted bytes. Binary-searching the CANN library set produced non-monotonic results — a 10-library subset loads cleanly while dropping one of several members makes it abort again — which is the signature of heap-layout-sensitive corruption rather than a deterministic API misuse.
GLIBC_TUNABLES=glibc.malloc.check=3also fails to catch it any earlier. Thefreeon the stack is a victim, not the culprit.Impact
Any short-lived process that imports
mooncake.storeand then exits normally is reported as failed by its parent, because the exit status is non-zero even though the work completed. Concretely, this breaks vLLM-Omni: the subprocess vLLM forks to inspect model architectures imports the whole vllm-omni package, so it dies on the way out and the parent refuses to start the deployment:This makes every Ascend deployment containing an LLM stage fail to start. Reported upstream in vllm-project/vllm-omni#8624, which works around it by no longer importing the optional connectors eagerly — but that only removes the accidental exposure; a deployment that genuinely selects a Mooncake connector still hits this abort.
We would appreciate any pointers on whether this is a known issue with the Ascend build, whether it is fixed in a newer wheel, or which component to follow up with.
@github-actions[bot] commented on GitHub (Oct 8, 2026):
Thanks for opening this issue, @brandneway!
53851298A maintainer will triage this when possible. To help us respond faster, please include:
Useful links: Documentation · Contributing guide
@ascend-direct-dev commented on GitHub (Oct 10, 2026):
更新0.3.12即可
@Adeshen commented on GitHub (Oct 14, 2026):
Additional evidence: vLLM Ascend v0.23.0 P/D API processes abort after SIGTERM
We observed a closely matching failure with
mooncake-transfer-engine-npu==0.3.11.post1in the vLLM Ascend v0.23.0 image, including a real model-serving shutdown failure. This appears related to this issue; we have not established that the underlying corrupting write is the same.I saw the recommendation to upgrade to 0.3.12. We have not yet retested that version. These are observations from the original pinned image, not a claim that 0.3.12 remains affected.
Environment
quay.io/ascend/vllm-ascend:v0.23.0.sha256:660ce23a83574fdcd28ba126b07615829c06770c06fbdf6533f03cc4d90acdb1(not a registry manifest digest).0fc695fc6d1d82e9a5ac6835ac8e4e1c83703665; Ascend commit:5cb98caaadeff42b5b62b996e34bb2aaa29d20fd, from the same-image environment record./usr/local/Ascend/cann-9.1.0/lib64/.--network nonecontainer, loopback communication.TORCH_DEVICE_BACKEND_AUTOLOAD=0. This is a different diagnostic environment from the real-device P/D run.Recorded installed package versions
Observed behavior
-6(SIGABRT),corrupted size vs. prev_size0libascendcl.soorlibllm_datadist.soindividuallyBODY_OK0libtransfer_engine.so,engine.so, or importmooncake.engineBODY_OK-6, same heap diagnosticThe P/D driver sends SIGTERM only to each API parent process, then waits up to 45 seconds; it does not signal the entire process group in this run. Both returned
-6, not the-9code of the driver's timeout fallback. The runtime logs show the defaultmode=abort timeout=0s; we did not test an explicitly configured graceful-drain mode.This primary P/D reproduction has no
sitecustomizeinstrumentation or patched production methods. Its driver exits 1 because it asserts that all API child exit codes must be 0. A separate earlier group-SIGTERM run is not used as the main evidence here.The no-connector control does not perform remote KV transfer or streaming cancellation; it is not a perfectly workload-matched ablation. We cannot attribute the corruption to the connector tracker, cancellation handling, or a particular CANN finalizer. No native backtrace identifying a corrupting write was captured in our runs.
Service evidence
The full source reproducer below starts P and D, compares real P/D generation against local generation, disconnects three streams, verifies recovery, and sends parent-only SIGTERM. The shutdown portions of the resulting API logs are shown first.
kv_consumer.log: shutdown excerpt (excerpt from original full log)
kv_producer.log: shutdown excerpt (excerpt from original full log)
Recorded process exit checks
pd-parent-sigterm/test_service.py — original script
pd-parent-sigterm/run-public.sh — public adaptation of recorded invocation
no-connector-control/test_service.py — original script
no-connector-control/run-public.sh — public adaptation of recorded invocation
Native isolation
The diagnostic below launches separate subprocesses and checks their actual return codes. Its wrapper itself exits 0 after collecting the failures; that does not mean the child tests passed. The direct
ascend_transport.soload has an unresolved-symbol error because it lacks its host library symbols; we do not treat that case as a production defect.native-isolation/diagnose.py — original script
native-isolation/run-public.sh
Native diagnostic result summary (derived from original results.json)
The two API crashes show a deployment lifecycle impact beyond standalone imports: the recorded P/D work completes, but service shutdown is reported as a process failure. We are adding this as corroborating evidence for the existing dependency issue, not a new independently established root cause. The next check is an isolated 0.3.12 retest of both import exit and this P/D shutdown workload while keeping other conditions fixed.