Describe the bug
On the GPU/GGUF backend (llama.cpp + ggml-hexagon DSP offload), geniex serve crashes the entire server process at the first DSP dispatch when a /v1/chat/completions request contains a system-instruction message. Crash signature:
ggml-hexagon.cpp:2233: ggml-hex: dspqueue_read failed: 0x00000072
Isolation results (each trial on a fresh serve):
- Trigger is the system message, not the output language — a preamble request with English output still crashes; a bare
user request with Chinese output does not.
- Not
max_tokens / output length — a bare request generating 277 tokens survives; a preamble request generating 1 token crashes.
geniex infer on the same GPU/weights/DSP works at the same moment → fault is specific to the serve chat path, not the device.- NPU (qairt) backend is unaffected.
- The crash kills the whole process; the offending POST never reaches the GIN access log.
To Reproduce (run on the serve host, fresh GPU/GGUF serve, unsloth/Qwen3-4B-Instruct-2507-GGUF:Q4_0)
- Crashing request — WITH system message:
{"model":"unsloth/Qwen3-4B-Instruct-2507-GGUF:Q4_0","messages":[{"role":"system","content":"You are a professional translator. Translate the user English text into Chinese. Output only the translation."},{"role":"user","content":"The quick brown fox jumps over the lazy dog near the riverbank."}],"max_tokens":64,"temperature":0}
- Serve prints
dspqueue_read failed: 0x00000072 and the process exits.
- Control — bare
user request, no system message (succeeds):
{"model":"unsloth/Qwen3-4B-Instruct-2507-GGUF:Q4_0","messages":[{"role":"user","content":"Translate into Chinese: The quick brown fox jumps over the lazy dog."}],"max_tokens":64,"temperature":0}
Note: the serve oscillates between a healthy window (requests succeed) and a fragile one. The system-message discriminator is deterministic within a fragile window; if step 1 succeeds on the first shot, repeat it until the serve drifts fragile.
Expected behavior
geniex serve should handle a request containing a system message without crashing — as geniex infer does. A bad request should at most return an HTTP error, never terminate the server.
Serve-side crash log
[GIN] 200 | GET "/v1/models"
[GIN] 200 | GET "/v1/models"
ggml-hexagon.cpp:2233: ggml-hex: dspqueue_read failed: 0x00000072
(The crashing POST /v1/chat/completions is absent — the process dies before the access-log line.)
Environment
- OS: Windows on ARM, build 28000 (Snapdragon)
- GenieX CLI:
v0.3.14
- QAIRT Runtime:
v2.45.0.260326
- LlamaCPP Hash:
be4a6a6
- Backend (crashing): GPU / GGUF (ggml-hexagon DSP offload); NPU/qairt unaffected
- Model:
unsloth/Qwen3-4B-Instruct-2507-GGUF (Q4_0)
Additional context
Suspected DSP-queue lifecycle issue on the serve dispatch path (stale/leaked dspqueue handle across the model destroy+reload cache, or a DSP init race). Evidence of a time-varying state: one serve logged 17 consecutive successes → 35 consecutive crashes → 6 successes, same process, no restart; a machine reboot did not reliably clear it.
Describe the bug
On the GPU/GGUF backend (llama.cpp + ggml-hexagon DSP offload),
geniex servecrashes the entire server process at the first DSP dispatch when a/v1/chat/completionsrequest contains a system-instruction message. Crash signature:Isolation results (each trial on a fresh serve):
userrequest with Chinese output does not.max_tokens/ output length — a bare request generating 277 tokens survives; a preamble request generating 1 token crashes.geniex inferon the same GPU/weights/DSP works at the same moment → fault is specific to theservechat path, not the device.To Reproduce (run on the serve host, fresh GPU/GGUF serve,
unsloth/Qwen3-4B-Instruct-2507-GGUF:Q4_0){"model":"unsloth/Qwen3-4B-Instruct-2507-GGUF:Q4_0","messages":[{"role":"system","content":"You are a professional translator. Translate the user English text into Chinese. Output only the translation."},{"role":"user","content":"The quick brown fox jumps over the lazy dog near the riverbank."}],"max_tokens":64,"temperature":0}dspqueue_read failed: 0x00000072and the process exits.userrequest, no system message (succeeds):{"model":"unsloth/Qwen3-4B-Instruct-2507-GGUF:Q4_0","messages":[{"role":"user","content":"Translate into Chinese: The quick brown fox jumps over the lazy dog."}],"max_tokens":64,"temperature":0}Note: the serve oscillates between a healthy window (requests succeed) and a fragile one. The system-message discriminator is deterministic within a fragile window; if step 1 succeeds on the first shot, repeat it until the serve drifts fragile.
Expected behavior
geniex serveshould handle a request containing asystemmessage without crashing — asgeniex inferdoes. A bad request should at most return an HTTP error, never terminate the server.Serve-side crash log
(The crashing
POST /v1/chat/completionsis absent — the process dies before the access-log line.)Environment
v0.3.14v2.45.0.260326be4a6a6unsloth/Qwen3-4B-Instruct-2507-GGUF(Q4_0)Additional context
Suspected DSP-queue lifecycle issue on the serve dispatch path (stale/leaked
dspqueuehandle across the model destroy+reload cache, or a DSP init race). Evidence of a time-varying state: one serve logged 17 consecutive successes → 35 consecutive crashes → 6 successes, same process, no restart; a machine reboot did not reliably clear it.