OVMS 2026.3 exits 139 (SIGSEGV) with no error message when loading an IR that requires a newer OpenVINO — reproduces on CPU

[lusoris]

Describe the bug

Loading the IR OpenVINO/Qwen3.8-27B-int4-ov on OVMS 2026.3.0.6f3df706b segfaults during servable initialisation. The process exits 139 roughly 5 seconds after the initialisation log line, writing zero compile-cache bytes and printing no error message at all:

[modelmanager][info][servable_initializer.cpp:568] Initializing Visual Language Model Continuous Batching servable
<process exits 139>

The model card for this IR states it requires OpenVINO >=2026.4.0, so an incompatibility is expected and reasonable. The bug being reported is the failure mode: an IR the runtime cannot handle should produce a clear "unsupported IR / requires OpenVINO >= X" diagnostic, not a bare SIGSEGV. Because there is no message at all, this is indistinguishable at the operator's end from OOM, a corrupt IR, a GPU driver fault or a bad --cache_dir, and we spent a full debugging cycle excluding each of those one at a time.

This matters on the current release: v2026.3 is the newest GA tag (published 2026-08-04), and no 2026.4 release tag is published, so the only way out today is the moving weekly dev image.

To Reproduce

1. Stage OpenVINO/Qwen3.8-27B-int4-ov (24 files, 15,707,650,330 B; openvino_language_model.bin = 13,929,177,378 B).
2. Run openvino/model_server:2026.3-gpu (sha256:2a52cd2bc62d984f35f12b1cf58bb5dffe5f5d57b6ef3349b1b37229a768806b) with:

--task=text_generation
--target_device=CPU
--plugin_config='{"ENABLE_CPU_PINNING":false}'
--tool_parser qwen3coder
--reasoning_parser qwen3
--kv_cache_precision u8
--cache_size 4
--enable_prefix_caching false
--max_num_seqs 2
--max_num_batched_tokens 4096

3. The process exits 139 after ~5 s with the log line above and nothing further.

Note --target_device=CPU. The crash reproduces on CPU with the same args, which is what rules out VRAM exhaustion, the GPU plugin and the GPU driver.

Expected behavior

A logged error identifying the IR as unsupported by this runtime — ideally naming the required OpenVINO version — and either a clean non-zero exit or a servable that transitions to a failed state, rather than SIGSEGV.

Logs

The same IR with the same args on openvino/model_server:weekly (sha256:7eb60804f86d7f47fd278a0cc1958fde5f8493534062ae69bef27dc5ba439cf2, OpenVINO Model Server 2026.4.0.e5e9afa28, backend 2026.4.0-22775-187288961b4, GenAI 2026.4.0.0-3367-df5ceab4273) loads correctly:

[modelmanager][info][servable_initializer.cpp:568] Initializing Visual Language Model Continuous Batching servable
[llm_calculator][info][servable_initializer.cpp:137] Using manually configured tool_parser: qwen3coder
[llm_calculator][info][servable_initializer.cpp:147] Using manually configured reasoning_parser: qwen3
[modelmanager][info][pipelinedefinitionstatus.hpp:59] Mediapipe: qwen3-8-27b state changed to: AVAILABLE after handling: ValidationPassedEvent:

AVAILABLE in 15 s on CPU and 33 s on GPU, generating correctly in both cases.

On 2026.3 the last line emitted is the servable_initializer.cpp:568 line and nothing follows it.

Things already excluded

• Not a truncated or corrupt IR — all 7,423 const offsets sum to exactly the 13,929,177,378-byte .bin, and the published SHA-256 of the primary artifact verifies.
• Not OOM — memory.events oom_kill 0, 934 MB in use against a 40 GB limit.
• Not an unsupported architecture per se — the previously working OpenVINO/Qwen3.6-27B-int4-ov declares the same qwen3_5 / Qwen3_5ForConditionalGeneration and loads fine on 2026.3. That IR's card requires only OpenVINO >=2026.2.0.
• Not a --cache_dir problem — zero cache bytes are written before the crash.
• Not GPU-specific — reproduces with --target_device=CPU.

Configuration

1. OVMS version: 2026.3.0.6f3df706b (image openvino/model_server:2026.3-gpu, digest above).
2. No config.json — started from command-line arguments as listed above.
3. Crash observed on CPU and on GPU. The GPU leg was measured on an Intel Arc A380 (DG2, i915) and on an Intel Arc Pro B60 (Battlemage, xe).
4. Model repository: the upstream OpenVINO/Qwen3.8-27B-int4-ov tree staged unmodified.
5. Publicly available model that reproduces: OpenVINO/Qwen3.8-27B-int4-ov itself.

Additional context

Known gaps in this report, stated plainly: no core dump or backtrace was captured, so I cannot point at the faulting frame. I am happy to collect one if you can tell me the preferred method for the container image (the container does not appear to write a core by default, and I would rather follow your intended procedure than guess at ulimit/core_pattern settings that may not apply inside the image).