SIGSEGV: POST /slots/{id}/save crashes the server when paged KV is enabled (incl. --prefix-cache)

[kira-ariaki]

Summary

On BaseRT 0.1.7 (macOS arm64), POST /slots/{id}/save reliably segfaults the entire server process whenever paged KV is active. The request never returns; every subsequent request fails with a connection error.

--prefix-cache implies --paged-kv, so any server started with prefix caching is affected. Since the endpoint requires no authentication when --api-key is unset, a single unauthenticated curl can terminate the process.

Without paged KV the same request returns 200 and the server stays up, which isolates the fault to the paged-KV path rather than to routing or request parsing.

Environment

• BaseRT 0.1.7, official macOS arm64 release bundle (basert --version → basert 0.1.7)
• macOS 26.4.1 (build 25E253), M1 Max 64 GB
• Model: basecompute/Qwen3-0.6B, default-q4 (a dense model — this is not hybrid-specific)

Reproduction

# 1. start with paged KV enabled
basert-serve --model .../basecompute/Qwen3-0.6B/default-q4/model.base \
  --port 8896 --host 127.0.0.1 \
  --max-context 40960 --files-dir /tmp/slotfiles \
  --paged-kv

# 2. warm the slot with any completion
curl -s -X POST http://127.0.0.1:8896/v1/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"basecompute/Qwen3-0.6B","prompt":"hello world","max_tokens":4}'

# 3. this kills the server
curl -X POST http://127.0.0.1:8896/slots/0/save \
  -H 'Content-Type: application/json' -d '{}'

Step 3 produces no HTTP response (HTTP=000). The process exits with:

Segmentation fault: 11

Flag matrix

Identical procedure, only the startup flags differ. Each row is a fresh process, warmed with one completion before the save call:

startup flags	POST /slots/0/save	server after
(none)	200 {"object":"slot.snapshot","file_id":"file-SZZlSsVBs2xP",...}	ALIVE
--paged-kv	HTTP=000	DEAD (SIGSEGV)
--prefix-cache	HTTP=000	DEAD (SIGSEGV)
--paged-kv --continuous-batching 4	HTTP=000	DEAD (SIGSEGV)

--prefix-cache implies --paged-kv per --help, so all three failing rows share the paged-KV path.

Not a routing / path-parsing problem

Bad path segments are rejected cleanly and the process survives, so the crash is specific to executing the save against a paged-KV cache:

POST /slots/1/save    -> 404 {"error":{"message":"Model not found",...}}   [ALIVE]
POST /slots/99/save   -> 404 {"error":{"message":"Model not found",...}}   [ALIVE]
POST /slots/bogus/save-> 404 {"error":{"message":"Model not found",...}}   [ALIVE]

Impact

• Any deployment using --prefix-cache (the recommended setting for shared-prefix workloads) can be terminated remotely by one request to an endpoint that requires no authentication.
• The crash takes down all models and all in-flight requests in the process, not just the affected slot.

Expected

POST /slots/{id}/save should either serialize the paged-KV cache successfully, or return a structured error (e.g. 400/501 "slot snapshot not supported with paged KV"), without terminating the process.