Kokoro ANE: libBNNS vadd_fp16_sme SIGSEGV reproduces on iOS 27.0 on the Metal-free route (#843's default); MPSGraph abort unchanged on 27 beta 8

[rfrmd]

Summary

Two data points from the field that bear on #843 / #844, both captured from devices, both on Kokoro ANE (the laishere chain via FluidAudio):

1. The libBNNS vadd_fp16_sme SIGSEGV reproduces on iOS 27.0 — on the exact route iPadOS 27.0 beta: default routing's GPU stages (noise/tail) abort in MPSGraph under CoreML — #667 family, new OS (FB24243070) #843 ships as the OS‑27 default (aneTailCpu: noise + tail on .cpuOnly, RNN stages on ANE). iPadOS 27.0 beta: default routing's GPU stages (noise/tail) abort in MPSGraph under CoreML — #667 family, new OS (FB24243070) #843 describes that route as "fine there" and the BNNS segfault as "a 26.x‑line bug (Kokoro ANE: libBNNS EXC_BAD_ACCESS is time/environment-gated — same binary flips 40/40 PASS to 0/15 CRASH same day (controlled evidence; follow-up to #328/#587) #817/Kokoro ANE: BnnsCpuInferenceOperation SIGSEGV still reproduces on iOS 26.6 (follow-up to #817) #844)". It is not 26.x‑only.
2. The MPSGraph abort (iPadOS 27.0 beta: default routing's GPU stages (noise/tail) abort in MPSGraph under CoreML — #667 family, new OS (FB24243070) #843) is unchanged on iOS 27 beta 8 (24A5430a) — re‑tested 2026‑09‑04 with the GPU route deliberately re‑armed.

Together: on the 27 line, by evidence, neither route survives — Metal aborts, and the BNNS fallback the Metal‑free route relies on segfaults intermittently, exactly as #817's title says ("time/environment‑gated — same binary flips 40/40 PASS to 0/15 CRASH"). Our BNNS crash came 54 minutes into a plain foreground listen; a short validation run would not see it.

1. BNNS SIGSEGV on iOS 27.0 — the Metal‑free route

Device	iPhone18,1 (iPhone 17 Pro, A19 Pro — SME‑class silicon, same class as #844's 17 Pro Max)
OS	iPhone OS 27.0 (24A5418b)
App	SchriftOhr 0.9.1 (460) (FluidAudio 0.15.5)
When	2026-08-24 20:16:27.0283 -0500 — ~54 min into a foreground listen
Routing	noise = .cpuOnly, tail = .cpuOnly, all other stages .cpuAndNeuralEngine — i.e. what 0.15.6 now ships as aneTailCpu
Exception	EXC_BAD_ACCESS (SIGSEGV) — KERN_INVALID_ADDRESS at 0x0000000158d3c000
Triggered by	Thread 8

0  libBNNS.dylib  0x00000002640f0c74 void vadd_fp16_sme_internal<(BNNSActivationFunction)0>(_Float16*, _Float16 const*, _Float16 const*, long long) + 420 (:-1)
1  libBNNS.dylib  0x00000002640f0aa8 void bnns_vadd_fp16_sme2p1<(BNNSActivationFunction)0>(_Float16*, _Float16 const*, _Float16 const*, unsigned long) + 52 (:-1)
2  libBNNS.dylib  0x0000000263bc3fd4 invocation function for block in int bnns::graph::execute_typed_binary_forwards<_Float16, _Float16, _Float16>(void (*)(_Float16*, _Float16 const*, _Float16 const*, unsigned long), void*, void const... + 372 (:-1)
3  libdispatch.dylib  0x00000001ce06afd8 _dispatch_client_callout2 + 16 (:-1)
4  libdispatch.dylib  0x00000001ce065d7c _dispatch_apply_invoke3 + 172 (:-1)
5  libdispatch.dylib  0x00000001ce06afc0 _dispatch_client_callout + 16 (:-1)
6  libdispatch.dylib  0x00000001ce053b60 _dispatch_once_callout + 32 (:-1)
7  libdispatch.dylib  0x00000001ce065130 _dispatch_once_f + 24 (:-1)
8  libdispatch.dylib  0x00000001ce065130 _dispatch_apply_invoke2 + 120 (:-1)

No app frame on the stack — the SIGSEGV is inside Apple's SME fp16 vector kernel, reached from bnns::graph::execute_typed_binary_forwards<_Float16> on a dispatch_apply worker: Core ML's own scheduler dispatching a boundary op to CPU/BNNS. Same family as #817 (26.5, iPhone 17e) and #844 (26.6, 17 Pro Max): 26.5, 26.6 and 27.0 all reproduce it on SME‑class chips.

2. MPSGraph abort still present on iOS 27 beta 8

Device	iPad16,2 (iPad mini, A17 Pro)
OS	iPhone OS 27.0 (24A5430a)
App	SchriftOhr 0.9.5 (531)
Signal	6 (SIGABRT), exceptionType 10
Routing	the normal ladder with the GPU stages on .cpuAndGPU, re‑armed on purpose to test the seed

Innermost frames (MetricKit callStackTree, deepest first):

libsystem_pthread.dylib
libsystem_pthread.dylib
MetalPerformanceShadersGraph
MetalPerformanceShadersGraph
libc++.1.dylib
libsystem_pthread.dylib
libsystem_kernel.dylib
libsystem_pthread.dylib

Same signature as #843 / FB24243070: assertion → abort() inside MetalPerformanceShadersGraph under Core ML, on a dispatch worker, no app frames. Minutes in.

What we do about it (for anyone shipping on 27)

We gate the neural voice off entirely on OS 27 and fall back to system voices, because a SIGSEGV or SIGABRT inside Apple's library cannot be caught in‑process and no fallback ladder runs. The per‑route re‑tests are behind self‑clearing tester switches (a crash while armed disarms it on next launch). Happy to share the full .ips and the MetricKit crash JSON for either crash — say the word and I'll attach them.

Filed with Apple: FB24243070 (Metal abort). The BNNS crash on 27 is attached to the same Feedback.

[rfrmd]

A data point from the other side of the fence, in case it helps narrow this down.

We put the same Kokoro-82M v1.0 model on ONNX Runtime's CPU execution provider (onnxruntime 1.24.2, no CoreML EP, no XNNPACK), fed by FluidAudio's own phonemizer, vocab and voice packs — KokoroAneManager.phonemes(for:), KokoroAneVocab.encode, style row chosen by phoneme count — so the only thing that changed is what executes the graph. Model file: onnx-community/Kokoro-82M-v1.0-ONNX, the int8 variant (model_quantized.onnx).

On iPad17,2 (iPad Pro 11-inch, M5) running iOS 27.0 beta 8 (24A5430a), that route read an entire book: about 2 h 34 min of continuous synthesis, screen off, plugged in, sentences never rendered before. No crash. The only system reports for the process were a cpu_resource note and a diskwrites_resource note, which is just the footprint of the work.

What we have seen from the CoreML paths, with the exact seeds:

• Metal-free route (iPadOS 27.0 beta: default routing's GPU stages (noise/tail) abort in MPSGraph under CoreML — #667 family, new OS (FB24243070) #843's default: noise and tail stages on CPU, the rest on the ANE): SIGSEGV in libBNNS vadd_fp16_sme_internal 54 minutes into a listen, iPhone18,1, iOS 27.0 (24A5418b), 2026-08-24 — the .ips in the first post. We have not yet completed a full hour on that route on 24A5430a, so we can't say from our own runs whether beta 8 changed it; nothing in beta 8's notes addresses it.
• Metal route (normal compute units): SIGABRT in MetalPerformanceShadersGraph within minutes on 24A5430a, reproduced this morning on both iPad17,2 and iPad16,2 (iPad mini, A17 Pro). Same failure as on the earlier seeds.

So the model, the phonemizer and the packs are fine; whatever is wrong sits in the CoreML execution path on iOS 27, and on the Metal side it is still there on the latest seed. Output matches the CoreML render closely — on an M-series Mac the fundamental frequency was identical (117.1 Hz on am_michael) and sentence length within a frame. Cost is the expected one: about 0.85 processor-seconds per second of speech versus 0.19 on the Neural Engine, which is why we ship it as a switch for people on the 27 betas rather than as a replacement.

Happy to share the exact session options or the resource reports if useful.

[Alex-Wengg]

Thanks for the detailed follow-up. This materially changes the conclusion from #843/#849: the OS-27 CPU/
ANE fallback route is not safe either.

The vadd_fp16_sme crash on the exact aneTailCpu route means we currently have evidence that both
available Core ML routes can terminate the process on iOS 27:

• GPU stages: uncatchable MPSGraph SIGABRT
• CPU/BNNS stages: uncatchable libBNNS SIGSEGV

The successful 2h34m ONNX CPU run is useful evidence that the model, phonemizer, and voice packs are not
the cause; the failure is in Apple’s Core ML execution path.

We’ll keep this issue open, revisit the OS advisory and tests that currently treat iOS 27 as unaffected,
and reconsider whether Kokoro ANE should be disabled by default on iOS 27 until a safe route is
demonstrated. Please attach the .ips and MetricKit artifacts when convenient, and we’ll use them
alongside the existing #843/#844 reports for a controlled follow-up.

[Alex-Wengg]

The advisory revisit from my last comment is up as #902: the whole iOS 27 line is now flagged, initialize() logs a route-aware warning on 27 that names both signatures and suggests disabling Kokoro ANE there, the route docs stop calling the CPU-tail route safe, and the known-issues table carries both 27-line rows. It changes no routing. Disable-by-default on iOS 27 stays the open decision on this issue; the .ips / MetricKit artifacts would still help for the controlled follow-up.

[billatq]

Interestingly enough, if you grab the bits that would run on CoreML and then just run them using Accelerate, it doesn't seem to crash. Example here: billatq@99a9fb4

Given that this seems broken on a lot of OS versions, I'm curious if it makes sense to do this in a less brittle way than my example.

[Alex-Wengg]

@billatq thanks, this is a useful experiment. Two things before treating it as the fix. The BNNS crash on the Metal-free route is in an fp16 kernel (vadd_fp16_sme_internal), and the Tail is an fp32 graph, so on that route the fp16 BNNS work comes from CPU fallback inside the ANE stages rather than from the Tail. Do you have a soak duration on the native-Tail build, and was it the aneTailCpu route? Two hours or more on that route would be the evidence that moves this.

On the code, the direction is right and we'd take a PR shaped like: the four Tail tensors exported from the converter into a small versioned file in the bundle instead of fixed offsets into the compiled weight.bin, a Core ML / Accelerate backend switch kept opt-in, and a parity test against the Core ML Tail on real model outputs. If the soak holds, a native Noise stage on the same pattern would remove the last fp32 Core ML stage from the CPU route.

[billatq]

I can check my crash logs. I know both CPU fallback and GPU were implicated and my app, which would happen every launch, would need to see if it's the 16 or 32 path, but I'll give
it a try.

[Alex-Wengg]

Thanks, let me know when you report back.