whisper : NULL-guard CPU device lookup in make_buft_list (fix #3497)

[TheBlueHouse75]

Summary

Three call sites in `src/whisper.cpp` dereference the CPU backend device returned by GGML without checking for NULL. With `GGML_BACKEND_DL=ON` builds, the registry starts empty (no backend is statically linked into `ggml-base`), and an embedder that calls `whisper_init_` or `whisper_vad_init_` before an explicit `ggml_backend_load*()` invocation hits `GGML_ASSERT(device != NULL)` inside `ggml_backend_dev_backend_reg`. On Windows the process is killed with `__fastfail(7)` (status `0xC0000409`, `FAST_FAIL_FATAL_APP_EXIT`) with no chance for the application to recover.

Closes #3497 (same symptom, Flutter Windows embedder).

Repro

Any `BUILD_SHARED_LIBS=ON` + `GGML_BACKEND_DL=ON` build, on a host without a CPU backend DLL pre-loaded by `ggml_backend_load_all()`:

```c
// 1. Process starts. ggml-base.dll registry is empty (no static GGML_USE_CPU).
// 2. Embedder calls:
struct whisper_vad_context_params p = whisper_vad_default_context_params();
p.use_gpu = false;
whisper_vad_init_from_file_with_params("silero.gguf", p);
// → make_buft_list → ggml_backend_dev_by_type(CPU) → NULL
// → ggml_backend_dev_backend_reg(NULL) → assert → __fastfail(7)
```

I hit this on a Windows MSI build that calls `whisper_vad_init_from_file_with_params` for Silero VAD before the main `whisper_init_*`. Full WinDbg dump + stack trace at https://github.com/TheBlueHouse75/simple-flow/tree/report/whisper-rs-vad-gpu-null-2026-05-19/reports/windows-whisper-rs-vad-gpu-null-2026-05-19 .

Patch

Site	Line (current master)	Function	Behavior
1	173	`ggml_graph_compute_helper` (CPU helper)	NULL-check `backend`, return `false`
2	1388	`make_buft_list` (called by `whisper_init_` and `whisper_vad_init_`)	NULL-check `cpu_dev`, return empty `buft_list`
3	8960	`whisper_exp_compute_token_level_timestamps_dtw`	NULL-check `backend`, early `return` (skip DTW for this segment)

All three log a clear `WHISPER_LOG_ERROR` message pointing embedders at `ggml_backend_load_all()` / `ggml_backend_load()` as the fix on their side. This mirrors the existing NULL-guard already present at line 1352 (`whisper_backend_init`).

Test plan

• CMake configure + build of `whisper` target on macOS (Accelerate + Metal), 0 warning, 0 new error.
• Build on Windows with `BUILD_SHARED_LIBS=ON` + `GGML_BACKEND_DL=ON`, confirm the `__fastfail(7)` is replaced by a clean WHISPER_LOG_ERROR + NULL context return.
• No regression on a default (GGML_BACKEND_DL=OFF) build that has a CPU backend statically registered (the guards take the happy path).

Why this matters

`GGML_ASSERT(device != NULL)` is the right invariant for internal code, but the C public API (`whisper_init_`, `whisper_vad_init_`) is reachable by embedders that may not know they must call `ggml_backend_load_all()` first — especially with the new VAD entry points (`whisper_vad_init_from_file_with_params`) shipped in 1.8.x. A process abort from inside a public C API call is hard to recover from for any high-level binding (Flutter, Rust, Python, …). Returning a NULL context + logging the error lets the binding surface a typed error to userland.

Happy to refactor (e.g. extract a shared `get_cpu_backend_or_log` helper) if you'd prefer. Kept the patches local and small for review.