[silverstein]

What

minutes watch aborts with SIGABRT on Ctrl-C when a transcription is still in flight, reported in #998:

ggml-metal-device.m:608: GGML_ASSERT([rsets->data count] == 0) failed

Why it happens

The watch handler at crates/cli/src/main.rs:7217 releases the lock and calls std::process::exit(0) from ctrlc's signal thread while the worker thread still holds a live WhisperContext. exit() runs __cxa_finalize, ggml's Metal device destructor runs with that context's buffers still registered in the residency-set collection, and ggml_metal_rsets_free asserts.

That reading is not inference. The reporter's stack has __cxa_finalize_ranges at frame 5 and _pthread_start at frame 12, which is the signal thread calling exit, and upstream states the cause directly above the assert:

// note: if you hit this assert, most likely you haven't deallocated all Metal resources before exiting

A signal handler cannot fix this by dropping the context, because the decode that owns it is running on another thread.

The fix

We already solved this class of bug once. #229 hit the same __cxa_finalize_ranges abort in the desktop worker subprocess and fixed it with a hard exit, but that helper was macOS-gated and private to the Tauri binary, so the CLI's interrupt paths never got it.

This adds exit_without_cxx_teardown to minutes-core, with explicit stdout and stderr flushing (_exit will not flush), and uses it from the four CLI interrupt paths that exit: watch, record, dictate, and the graceful-stop handler. Non-macOS targets keep the ordinary exit, since the aborting teardown is Metal's.

The Tauri copy is deliberately left in place rather than pointed at the core one. That dedup is tempting, but tauri/src-tauri/src/main.rs is covered in full by the Apple Speech authority golden hash, and that hash exists precisely so edits to that file are deliberate. I had the delegation written and backed it out: re-sealing a hash that guards an XPC authority boundary in order to tidy a ten-line helper is the wrong trade, and it belongs in a change that is actually about that file.

Adversarial review found a defect in the first revision

Worth recording, because the bug was in the fix rather than in the original code.

The first revision flushed stdout before _exit, reasoning that _exit skips the flushing exit() does. That was a regression on every platform, including the non-macOS ones this change otherwise leaves alone. Stdout::flush takes the process-wide stdout lock, so a thread already blocked writing into a stalled pipe (say minutes dictate piped to a consumer that stopped reading) holds that lock, and the force-quit blocks on it forever. Rust's own exit cleanup avoids exactly this with try_lock.

Verified standalone before changing anything: with the flush, the process hung; without it, it exited 23 immediately. A crash turned into an unkillable hang is a worse trade than the one it was meant to fix.

The flush is gone, and exit_without_cxx_teardown_does_not_block_on_a_held_stdout_lock now guards it: re-execute the test binary, hold the stdout lock on another thread, assert the child still exits. Confirmed it fails (30s hang) when the flush is put back and passes when it is removed, so it catches the defect rather than merely passing. It needs no GPU backend, so unlike the Metal abort it runs everywhere CI builds.

Verification

Reproduced and verified on macOS 26.6, Apple Silicon, built --features metal, in an isolated HOME so no real meeting data was touched. Interrupt during an in-flight decode:

• before: exit 134 with the assert, every run
• after: exit 0, no assert, four runs out of four

cargo fmt --all -- --check and cargo clippy --all --no-default-features -- -D warnings are clean.

What this does not cover

Two things, stated plainly rather than left for someone to discover.

No regression guard is possible in the current CI matrix. Nothing in CI builds with metal, so this abort cannot reproduce there and no test in this PR would catch a regression. The honest fix is a small macOS Metal smoke job that starts watch, interrupts it mid-decode, and asserts the exit status is not a signal. Filing that separately.

The desktop half of #998 is not closed. The reporter also saw the abort on desktop app shutdown. The app's explicit clean-exit route already skips teardown via finish_clean_exit, so the remaining exposure is any path where the run loop returns from main instead, which still runs destructors. That needs its own audit, so this is Refs #998 rather than Fixes.

🤖 Generated with Claude Code