First `ctx.completion()` throws `Exception in HostFunction: <unknown>` on Samsung Exynos (qwen3-0.6b / TinyLlama / gemma4-e2b-lite, both with and without `no_extra_bufts: true`)

[eckonode]

Repro environment

• llama.rn versions tested: 0.12.0-rc.4 (cpp pin: build b8665, commit b863507) and 0.12.0-rc.9 (cpp pin: build b8827, commit 5e6c0e1). All RC versions in the rc.5 → rc.9 range reproduce the same JS-layer error.
• React Native: 0.81.5, Hermes engine
• Expo SDK: 54
• Devices reproducing the crash (both Samsung Exynos):
  • Samsung Galaxy A50 (SM-A505U), Exynos 9610 (Cortex-A73 + A53, ARMv8.0-A baseline), 3.5 GB RAM, Android 11 / API 30
  • Samsung Galaxy A25 5G (SM-A256U), Exynos 1280 (s5e8825, Cortex-A78 + A55, ARMv8.2-A + dotprod), 5.5 GB RAM
• APK type: debug build, sideloaded via adb install -r. JS bundle served by npx expo start Metro at runtime (no in-APK bundle).
• Snapdragon / MediaTek devices: not yet tested. We are explicitly trying to make the Exynos path work rather than gate it off, so cross-platform falsification is pending hardware.

Failure mode

The very first call to ctx.completion(...) after a successful cold init fails on the JS side with:

[ReasoningService] completeWithReasoning failed: [Error: Exception in HostFunction: <unknown>]
[ReasoningService] JSI HostFunction crash detected — disabling reasoning for the rest of this session.

After this throw, the process stays alive but every subsequent ctx.completion(...) returns immediately because the consuming app trips a JSI-corruption circuit-breaker (our F5 — see "What's been ruled out" below). Any ctx.completion(...) calls already in flight at the moment of the throw eventually time out at our 30 s wrapper timeout.

The <unknown> is React Native + Hermes' generic fallback wrapper for any C++ throw whose .what() it can't translate (RN #34730). PR #318's resultGenerator try/catch does not catch this throw — <unknown> persists in rc.9. Either the throw is not in the resultGenerator path, is not std::exception-derived, or fires before the resultGenerator is reached.

Reproducible steps

1. npm install llama.rn@^0.12.0-rc.9. Native artifacts download via the rc.5+ postinstall script.
2. Call initLlamaContext with these params (matches what we use in production):

   await initLlamaContext({
     model: toNativeModelPath(modelUri),
     n_ctx: 2048,
     use_mmap: true,
     use_mlock: false,
     n_gpu_layers: 0,
     no_extra_bufts: true,   // optional; reproduces with `false` too
   });

3. Load any of: qwen3-0.6b-Q4_K_M, tinyllama-1.1b-chat-v1.0.Q4_K_M, gemma-4-E2B-it-UD-IQ3_XXS. We've seen the same failure on all three.
4. Cold init succeeds. loadModel logs Context initialized with n_seq_max = 1 and attachThreadpoolsIfAvailable: Attached ggml threadpool (n_threads=4, n_threads_batch=4). Latency: ~3.3 s on A50 with TinyLlama 1.1B Q4_K_M, ~10.8 s on A25 with gemma4-e2b-lite IQ3_XXS.
5. Call ctx.completion({ messages: [{role:'system',content:...},{role:'user',content:...}], n_predict: 512, temperature: 0.1, stop: [...] }) with a ~150–250-token prompt.
6. loadPrompt logs Input processed: n_past=N, embd.size=M for the prompt batch.
7. ~30 ms after the prompt-processed log, the Promise rejects with [Error: Exception in HostFunction: <unknown>].

Expected: completion returns a token stream, OR if it errors, the JS-side error has a meaningful .what() string.

Observed: opaque <unknown> on every variant tested.

Native tombstone

The opaque <unknown> is the catchable-exception code path. There's a second path that surfaces the underlying abort directly: llama.rn 0.12.0-rc.4 + no_extra_bufts: true produces a SIGABRT in lm_ggml_abort from llm_graph_context::build_inp_embd, with the process dying. This is a separate bug specific to rc.4's older cpp pin (b8665 / b863507); it is fixed in rc.9's pin (b8827 / 5e6c0e1). I include it because (a) the abort site gives us the only native stack trace we have for this device/model combination, and (b) the call stack lands inside the same decode → process_ubatch → build_graph → build_inp_embd path that the <unknown> variant exits through.

05-02 10:07:54.019 F libc:  Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE) in tid 13270 (mqt_v_native), pid 30806
05-02 10:07:54.578 F DEBUG: pid: 30806, tid: 13270, name: mqt_v_native  >>> com.eckonode.callibear <<<
05-02 10:07:54.578 F DEBUG: signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
05-02 10:07:54.578 F DEBUG: ABI: 'arm64'
05-02 10:07:54.578 F DEBUG: Build fingerprint: 'samsung/a50sq/a50:11/RP1A.200720.012/A505USQSKDWB1:user/release-keys'
05-02 10:07:54.589 F DEBUG: backtrace:
05-02 10:07:54.589 F DEBUG:   #00 pc 0000000000089cd0  /apex/com.android.runtime/lib64/bionic/libc.so (abort+164)
05-02 10:07:54.589 F DEBUG:   #01 pc 0000000000303e0c  base.apk!librnllama_v8.so (lm_ggml_abort+224) BuildId: 42fed8ee605fc9fabb2de8a1bb5d8e18c892eb6d
05-02 10:07:54.590 F DEBUG:   #02 pc 000000000044957c  base.apk!librnllama_v8.so (llm_graph_context::build_inp_embd(lm_ggml_tensor*) const+1612)
05-02 10:07:54.590 F DEBUG:   #03 pc 00000000007648a4  base.apk!librnllama_v8.so (llm_build_llama<false>::llm_build_llama(llama_model const&, llm_graph_params const&)+160)
05-02 10:07:54.590 F DEBUG:   #04 pc 00000000004fc798  base.apk!librnllama_v8.so
05-02 10:07:54.590 F DEBUG:   #05 pc 00000000004fc1bc  base.apk!librnllama_v8.so (llama_model::build_graph(llm_graph_params const&) const+1296)
05-02 10:07:54.590 F DEBUG:   #06 pc 000000000041d934  base.apk!librnllama_v8.so (llama_context::process_ubatch(llama_ubatch const&, llm_graph_type, llama_memory_context_i*, lm_ggml_status&)+908)
05-02 10:07:54.591 F DEBUG:   #07 pc 000000000041f2f0  base.apk!librnllama_v8.so (llama_context::decode(llama_batch const&)+2092)
05-02 10:07:54.591 F DEBUG:   #08 pc 0000000000717664  base.apk!librnllama_v8.so (rnllama::llama_rn_context_completion::nextToken()+200)
05-02 10:07:54.591 F DEBUG:   #09 pc 000000000071844c  base.apk!librnllama_v8.so (rnllama::llama_rn_context_completion::doCompletion()+56)
05-02 10:07:54.591 F DEBUG:   #10 pc 000000000006cda8  base.apk!librnllama_jni_v8.so  BuildId: d6357eb959de320ac4efc2c34747afc1eec2ae72
05-02 10:07:54.591 F DEBUG:   #11 pc 0000000000091cf0  base.apk!librnllama_jni_v8.so
05-02 10:07:54.592 F DEBUG:   #12 pc 000000000009af94  base.apk!librnllama_jni_v8.so
05-02 10:07:54.592 F DEBUG:   #13 pc 00000000000eb7a8  libc.so (__pthread_start(void*)+64)
05-02 10:07:54.592 F DEBUG:   #14 pc 000000000008bc8c  libc.so (__start_thread+64)
05-02 10:07:58.963 I Zygote: Process 30806 exited due to signal 6 (Aborted)

The crashing thread is named mqt_v_native (React Native's mqt JSI worker thread). On the A50 (Cortex-A53, ARMv8.0-A baseline) the picker correctly selects librnllama_v8.so (compiled with -march=armv8-a, no extensions) — confirmed via RNLlama.java:190 reading /proc/cpuinfo features fp asimd evtstrm aes pmull sha1 sha2 crc32 cpuid (no asimddp, no i8mm, no fphp, no atomics).

Variant matrix (every combination tested on the A50)

	llama.rn	no_extra_bufts	Outcome	JS error string
1	rc.4	not set	F5 trip, app survives	<unknown>
2	rc.4	true	SIGABRT in build_inp_embd, process dies	<unknown> (then abort)
3	rc.9	not set	F5 trip, app survives	<unknown>
4	rc.9	true	F5 trip, app survives	<unknown>

A25 5G reproduces variants 1, 3, 4 with the same JS-layer signature (different active model: gemma4-e2b-lite — confirms the bug is not model-specific).

What's been ruled out (single-variable on-device experiments)

• Wrong .so variant: picker logic in RNLlama.java:190 correctly selects librnllama_jni_v8 for Cortex-A53 (no asimddp) and librnllama_jni_v8_2_dotprod for Cortex-A55. Confirmed live via nativeloader logs in logcat.
• Hexagon backend leakage: isHexagonSupported() correctly returns false on Samsung Exynos (no Qualcomm hint, no Snapdragon SOC pattern, no Hexagon codename). HTP libs are extracted to app_rnllama-htp/ but never dlopen'd.
• OOM-killed worker thread: no_extra_bufts: true measurably reduces the Android lmkd (lowmemorykiller) cascade severity around the trip from ~8 procs killed/second to ~4 procs killed/second on the A50, but the F5 trip persists. Memory pressure is a contributing factor, not the root cause.
• Concurrent JSI calls: duplicate loadPrompt:215 [DEBUG] Input processed log lines from threads in the same millisecond come from llama.cpp's internal multi-threaded prompt batching (n_threads=4), not parallel ctx.completion() calls.
• Model-specific bug: three different reasoning models reproduce — qwen3-0.6b-Q4_K_M, tinyllama-1.1b-chat-Q4_K_M, gemma-4-E2B-it-UD-IQ3_XXS.
• RAM-tier issue: 3.5 GB (A50) and 5.5 GB (A25 5G) both reproduce.
• llama.rn version range: rc.4 through rc.9 all reproduce. PR fix: handle exception in createPromiseTask resultGenerator #318 (rc.5+) is in the codepath but does not catch this throw.

Asks

1. Is there a known crash on first ctx.completion() on Samsung Exynos that we've missed in the issue tracker? We searched but didn't find a direct match.
2. Can the <unknown> wrapper be widened to expose the actual .what() for whatever throw path is firing here? PR fix: handle exception in createPromiseTask resultGenerator #318 was supposed to do that for resultGenerator throws — it doesn't seem to apply on this device class. We're happy to test a debug build that adds extra logging at any catch point you suggest.
3. We haven't tested with n_threads: 1 yet (default appears to be 4 from attachThreadpoolsIfAvailable: Attached ggml threadpool (n_threads=4, n_threads_batch=4)). Worth testing whether this is a llama.cpp threadpool issue specific to multi-core Exynos? Happy to run that experiment if it'd be useful.
4. Is anyone else hitting this on Exynos? We searched the issue tracker and PocketPal llama.cpp has updated its support for Android Gpus, can we follow up？ #107 lists Galaxy Note10 Lite (Exynos 9810, sibling of our 9610) on its known-crash catalogue — suggesting this isn't device-unique.

I have detailed logs (full per-variant logcat, complete tombstone, /proc/cpuinfo for both devices, build IDs for the loaded .sos) ready to share if any of it would help narrow this. Happy to test patches against the Exynos hardware we have plugged in.

[eckonode]

Cross-device falsification — A25 5G native tombstones (issue body only had A50)

Adding native-side evidence for the A25 5G that wasn't in the original issue body. The OP table listed A25 5G as reproducing, but only the A50 native tombstone was pasted. Five A25 tombstones from the last 24 h are summarised below. They confirm the crash family is the same (mqt_v_native thread → lm_ggml_abort → libc abort), but the failing ggml op varies — which is itself a data point.

Device specs (A25 5G)

• Samsung Galaxy A25 5G, model SM-A256U
• SoC Exynos 1280 (s5e8825 / universal8825), Cortex-A78 + A55, ARMv8.2-A + dotprod
• 5.5 GB RAM
• Android 16 (SDK 36), build BP2A.250605.031.A3
• Build fingerprint: samsung/a25xsq/a25x:16/BP2A.250605.031.A3/A256USQSBDZB2:user/release-keys
• Selected native variant: librnllama_v8_2_dotprod.so (correct — the picker honours asimddp)

App / dependency

• llama.rn ^0.12.0-rc.4 (no version bump from the original report — we have not landed the rc.9 + no_extra_bufts: true experiment described in the OP, so the variant 1 / no-flag path is what's being exercised)
• React Native 0.81.5, Hermes
• Expo SDK 54
• Captures via adb -s <serial> shell dumpsys dropbox --print — read-only, no interaction with the device beyond what the user did organically

Reproduction status: YES (5 tombstones / 24 h)

Local time	Reasoning model	Top non-abort frame	Phase
2026-05-01 17:21:54	Qwen3-0.6B-Q4_K_M.gguf	cpy_k → build_attn → llm_build_qwen3	graph build
2026-05-01 22:09:57	Qwen3-0.6B-Q4_K_M.gguf	cpy_k → build_attn → llm_build_qwen3	graph build
2026-05-02 01:02:24	Qwen3-0.6B-Q4_K_M.gguf	cpy_k → build_attn → llm_build_qwen3	graph build
2026-05-02 13:21:44	gemma-4-E2B-it-UD-IQ3_XXS.gguf	(gemma family, build phase)	graph build
2026-05-02 13:51:59	gemma-4-E2B-it-UD-IQ3_XXS.gguf	lm_ggml_compute_forward_set_rows → lm_ggml_graph_compute	compute

Sample A25 tombstone — gemma-4-E2B, 2026-05-02 13:51:59

Build fingerprint: 'samsung/a25xsq/a25x:16/BP2A.250605.031.A3/A256USQSBDZB2:user/release-keys'
ABI: 'arm64'
Process uptime: 1809s
Cmdline: com.eckonode.callibear
pid: 9950, tid: 11536, name: mqt_v_native  >>> com.eckonode.callibear <<<
signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------

backtrace:
  #00 libc.so abort+156
  #01 librnllama_v8_2_dotprod.so lm_ggml_abort+224
  #02 librnllama_v8_2_dotprod.so lm_ggml_compute_forward_set_rows+1000
  #03 librnllama_v8_2_dotprod.so [unsymbolized]
  #04 librnllama_v8_2_dotprod.so lm_ggml_graph_compute+220
  #05 librnllama_v8_2_dotprod.so [unsymbolized]
  #06 librnllama_v8_2_dotprod.so lm_ggml_backend_sched_graph_compute_async+2772
  #07 librnllama_v8_2_dotprod.so llama_context::graph_compute(lm_ggml_cgraph*, bool)+172
  #08 librnllama_v8_2_dotprod.so llama_context::process_ubatch(...)+1096
  #09 librnllama_v8_2_dotprod.so llama_context::decode(llama_batch const&)+2092
  #10 librnllama_v8_2_dotprod.so rnllama::llama_rn_context_completion::nextToken()+200
  #11 librnllama_v8_2_dotprod.so rnllama::llama_rn_context_completion::doCompletion()+56
  #12..#14 librnllama_jni_v8_2_dotprod.so
  #15 libc.so __pthread_start
  #16 libc.so __start_thread

mmap region for the model:
  00000071'73b98000-00000071'ffffffff r-- f15000 8c468000  /data/data/com.eckonode.callibear/files/local-ai/v1/reasoning/gemma-4-E2B-it-UD-IQ3_XXS.gguf

Sample A25 tombstone — Qwen3 0.6B, 2026-05-01 17:21:54 (one of three matching this signature)

Build fingerprint: 'samsung/a25xsq/a25x:16/BP2A.250605.031.A3/A256USQSBDZB2:user/release-keys'
ABI: 'arm64'
Cmdline: com.eckonode.callibear
pid: 16768, tid: 19839, name: mqt_v_native  >>> com.eckonode.callibear <<<

backtrace (top frames only):
  #00 librnllama_v8_2_dotprod.so [unsymbolized]
  #01 librnllama_v8_2_dotprod.so [unsymbolized]
  #02 librnllama_v8_2_dotprod.so llama_kv_cache::cpy_k(lm_ggml_context*, lm_ggml_tensor*, lm_ggml_tensor*, int, llama_kv_cache::slot_info const&) const+320
  #03 librnllama_v8_2_dotprod.so llm_graph_context::build_attn(...)+560
  #04 librnllama_v8_2_dotprod.so llm_build_qwen3::llm_build_qwen3(...)+1240
  #05 librnllama_v8_2_dotprod.so [unsymbolized]
  #06 librnllama_v8_2_dotprod.so llama_model::build_graph(llm_graph_params const&) const+1636
  #07 librnllama_v8_2_dotprod.so llama_context::process_ubatch(...)+908
  #08 librnllama_v8_2_dotprod.so llama_context::decode(llama_batch const&)+2092
  #09 librnllama_v8_2_dotprod.so rnllama::llama_rn_context_completion::nextToken()+200
  #10 librnllama_v8_2_dotprod.so rnllama::llama_rn_context_completion::doCompletion()+56
  #11..#13 librnllama_jni_v8_2_dotprod.so

mmap region for the model:
  00000079'48951000-00000079'5fc47fff r-- 5ad000 172f7000  /data/data/com.eckonode.callibear/files/local-ai/v1/reasoning/Qwen3-0.6B-Q4_K_M.gguf

What this adds beyond what's in the issue body

1. Native A25 tombstones were missing from the original report — only A50 was pasted. The A25 reproductions cited in the OP table were JS-side only.
2. The failing op varies on A25. Three distinct ggml ops (cpy_k, build_attn, set_rows) hit the controlled lm_ggml_abort across five tombstones, on two different model architectures (qwen3, gemma). The A50, by contrast, deterministically lands at build_inp_embd → llm_build_llama for TinyLlama every time.
3. Compute-phase abort, not just build-phase. The 2026-05-02 13:51:59 tombstone fires from lm_ggml_compute_forward_set_rows inside lm_ggml_graph_compute — i.e. after process_ubatch finished building the graph and started executing it. The A50 evidence is all build-phase (process_ubatch → build_graph → build_inp_embd). So the abort is not strictly tied to graph construction; it can happen mid-execution as well.
4. Process uptime at crash on A25 = 1809 s (~30 min). The "first ctx.completion()" framing of the bug is a JS-side observation (the F5 circuit-breaker disables further completions after the first failure). The native worker can abort mid-session too — the JS side just doesn't reach a second native call to observe it.

Implication for the upstream framing (offered tentatively)

The op-variance (build_inp_embd on A50, cpy_k/build_attn/set_rows on A25, across two model architectures, including one compute-phase site) argues against a deterministic bounds bug at any single llama.cpp call site. The common factor across all 5 A25 tombstones and all observed A50 tombstones is the controlled lm_ggml_abort macro firing inside llama_context::decode/process_ubatch from the React Native module worker thread on Samsung Exynos — which is consistent with a memory-pressure trigger surfacing at whatever ggml allocation the kernel reclaims pages from next, rather than a deterministic source bug.

If a maintainer wants the full 364 KB dumpsys dropbox --print output for either device (memory map, registers, additional thread state), happy to attach as a gist — left out here to keep the comment focused.

— filed from a read-only research session; no PR or version bump attached.

[eckonode]

Update — 2026-05-24 — refined crash signature, falsification of four hypotheses, and a likely upstream mul_mat root cause

Filing a comprehensive update on this issue after a three-week investigation. The original report's "JSI HostFunction exception" was the user-visible front of a native SIGSEGV inside llama_decode; we've since isolated the native worker into a separate Android subprocess (so we can capture clean tombstones) and falsified four hypotheses through staged fix-forward PRs. The crash is now deterministic at one source-line offset across multiple builds, multiple compile variants, and a ~600-commit version bump. This points to an upstream mul_mat heap-corruption bug rather than anything llama.rn-specific. Posting this as evidence for a maintainer to triage; we do NOT claim definitive root-cause.

Refined crash signature

Every recent crash has this canonical fingerprint:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR)
Fault address: 0xb400006xxxxxxxxx  (Scudo allocator high-tagged-pointer range)

backtrace:
  #00 libc.so      __memcpy_aarch64_simd+80
  #01 librnllama_v8_2.so      lm_ggml_compute_forward_mul_mat+22XX
  #02 librnllama_v8_2.so      [unsymbolized]
  #03 librnllama_v8_2.so      lm_ggml_graph_compute+220
  #04 librnllama_v8_2.so      [unsymbolized]
  #05 librnllama_v8_2.so      lm_ggml_backend_sched_graph_compute_async+2772
  #06 librnllama_v8_2.so      llama_context::graph_compute+172
  #07 librnllama_v8_2.so      llama_context::process_ubatch+1112
  #08 librnllama_v8_2.so      llama_context::decode+2064
  #09 librnllama_v8_2.so      llama_decode+12
  #10 libllm_worker_jni.so    nativeBeginCompletion+1360
  #11 art interpreter / ART quick frames → Java thread pool worker

Two important details:

1. Scudo-tagged fault address. The 0xb4 prefix is Android's MTE / Scudo tag range — these are NOT null derefs or randomly bad pointers. They are __memcpy calls landing on heap memory whose allocator state has been corrupted. This is the canonical signature of latent heap corruption surfacing in the largest pointer-dense consumer downstream (mul_mat's GEMM kernels do a lot of memcpy).
2. The +22XX offset is deterministic. Across 8+ tombstones spanning two different binary variants and four llama.rn versions, the crash lands at mul_mat+2212 or mul_mat+2260 — a narrow ~50-byte range, every time. That's a specific source-line crash, not random graph traversal.

Environment

Field	Value
llama.rn	0.12.3 (latest stable at time of writing)
Bundled llama.cpp build	b9254 (~600 commits ahead of the b8665 we originally reported on)
Model	Qwen3-0.6B-Q4_K_M.gguf (canonical config)
React Native	0.81.5, Hermes engine
Expo SDK	54
Native variant selected	librnllama_v8_2.so (non-dotprod ARMv8.2-A)
Device	Samsung Galaxy A25 5G (SM-A256U), Exynos 1280 (s5e8825, Cortex-A78 + A55, ARMv8.2-A + dotprod, no i8mm), 5.5 GB RAM, Android 16
Runtime config	n_threads=1, BIG-cluster sched_setaffinity, n_ctx=1024, single-batch decode
APK type	releaseDebuggable, native worker isolated in a separate :llmWorker subprocess via android:process

Falsification chain — four hypotheses ruled out

This is the part we think is most useful to a maintainer. Each hypothesis got its own focused PR + rig-verified test, with the same crash signature observed afterward.

Hypothesis	What we tried	Result	Conclusion
Q4_K-family CPU weight repack writer corruption (issue #19561, PR #17494 Cabrera bisect)	Set mparams.use_extra_bufts = false in nativeLoadContext to disable the dotprod-only block-interleave rewrite	4 SIGSEGVs in 18 min on the post-fix build, kernel signature CONVERGED to mul_mat+2212 (pre-fix it rotated across kernels)	Repack writers were noise on top of the underlying bug. Repack-off SIMPLIFIED the crash to a deterministic signature, didn't fix it.
Compile-time dotprod-keyed codegen bug (Cabrera precedent #18783 — +dotprod builds historically more fragile in mul_mat)	Variant promotion in VariantPicker.kt: skip dotprod-keyed entries so A25 selects librnllama_v8_2.so instead of librnllama_v8_2_dotprod.so	3 SIGSEGVs in 19 min on the non-dotprod variant, SAME +2212 offset	The bug is at a SOURCE-LINE point in mul_mat, not specific to any one compile flag.
Use-after-free in llama_memory_clear(mem, data=true) interaction with the next llama_decode (stale buffer pointer hypothesis)	Changed both llama_memory_clear call sites in the JNI to data=false (clear metadata only, preserve data buffers across resets)	1 SIGSEGV in 19 min (down from 3, ~67% reduction), same signature	Partial improvement — but the residual crash at the SAME +2212 offset says another path to a stale pointer is still active. Not the root cause.
Stale llama.cpp version (b8665 missing recent upstream fixes)	Bumped llama.rn 0.12.0-rc.4 → 0.12.3, which carries llama.cpp b8665 → b9254 (~600 commits forward)	1 SIGSEGV at 36m46s of sustained load, same signature, mul_mat+2212	The ~600-commit version bump did not close this. Not a fixed-upstream issue.

The composition of all four mitigations (use_extra_bufts=false + non-dotprod variant + memory_clear(data=false) + b9254) reduced the crash rate from "minutes-to-first-crash" to "~30-90-min-to-first-crash" — but did not eliminate it. The remaining crash sits at the SAME mul_mat+2212 offset.

Reproduction conditions

The crash occurs under sustained completion load. Our reproducer is a "cv-corpus-22" rig that runs real-audio transcriptions through completion in a loop, plus periodic enrichment passes. On the post-all-four-mitigations build:

• First crash uptime: 36m46s → 42m29s → 91 min across successive PR builds (the trend is the staged hypothesis chain working as defense-in-depth, even though no single fix is curative).
• Crash rate at steady state: 1 SIGSEGV per 30–90 min of sustained load.
• Crash is recoverable, not data-lossing: our subprocess isolation + IBinder.linkToDeath + JS-side recovery flow means the user-visible impact is bounded — but the underlying mul_mat bug remains.

Likely related upstream issue

ggml-org/llama.cpp issue #18392 — "Core dump for Q4_K_M model" — labeled regression, reproducing buffer-overflow on aarch64 with Qwen3-0.6B-Q4_K_M.gguf (the exact model + quantization we run). Open as of 2026-05-23. The symptom fingerprint (aarch64 + Qwen3-0.6B-Q4_K_M + heap corruption surfacing in a downstream kernel) matches our evidence closely. The fixes for #19561 (PR #19575, merged 2026-02-13) and the Q5/Q6_K work in PR #19356 ARE in our b9254 build — so the residual corruption that #18392 documents is downstream of what those PRs closed.

We can't reproduce on non-Exynos devices yet (the test-device fleet is currently A25-only), so an A25-or-Exynos-1280-specific factor isn't ruled out — but the source-line determinism across two compile variants argues against it being silicon-specific.

What we're asking

This is strong empirical evidence of a remaining upstream heap-corruption bug in lm_ggml_compute_forward_mul_mat, exercised by Q4_K-quantized models on aarch64. We're not claiming definitive root cause — we don't have aarch64-CPU expertise to disassemble the +2212 site or bisect upstream b9254 against the corruption — but the falsification chain narrows the search to within mul_mat's memcpy path, downstream of the Q4_K repack writers, on aarch64 builds.

Would a maintainer be willing to:

1. Confirm whether the mul_mat+22XX Scudo-tagged-pointer signature is consistent with known-or-suspected upstream bugs (perhaps a related-to-#18392 tail)?
2. Suggest whether disassembling at lm_ggml_compute_forward_mul_mat+2212 in librnllama_v8_2.so (we can supply the symbolized addr2line output) would tell you which source-line is implicated?
3. Flag if there's an additional A/B we could run from the binding side that would help narrow this further (e.g. swapping Qwen3-0.6B-Q4_K_M for Qwen3-0.6B-Q5_K_M to test if it's Q4_K-specific, which we'd happily do)?

Happy to attach the full tombstones, the addr2line symbolization of +2212, or any other diagnostic on request. Left out of this comment to keep it focused.

Cross-references for context:

• ggml-org/llama.cpp issue #18392 — open, aarch64 Q4_K_M core dump
• ggml-org/llama.cpp issue #19561 — closed by #19575, the repack-writer bisect
• ggml-org/llama.cpp PR #19575 — Q4_K block-interleave fix (in b9254)
• ggml-org/llama.cpp PR #19356 — Q5/Q6_K dotprod buffer accounting (in b9254)
• ggml-org/llama.cpp issue #18783 — dotprod codegen precedent

Thanks for keeping llama.rn going; the subprocess-isolation work we built on the binding side is what made this evidence base possible.