[ci-flake] android-harness-native-crash — off-thread data-binding SIGSEGV

[mfazekas]

Signature: android-harness-native-crash
Regex: (SIGSEGV | bridge disconnected | global reference table overflow) in the harness test step
Category: product-bug
First seen: 2026-06-29 · Last seen: 2026-07-06

Occurrence log

• 2026-06-29 — test-harness-android — intermittent "App bridge disconnected" = native heap-corruption SIGSEGV (reproduced locally ~1-in-10 runs)
• 2026-07-06 — production (Discord, Sentry DISCORD-ANDROID-3NFN) — SIGSEGV in rive::DataBindContainer::updateDataBinds via cppAdvance; fixed on their side by rive-android 11.6.2 (see comment below; mitigation fix(android): bump rive-android to 11.6.2 #317)

Hypothesis

This is a real bug, not infra — do not just re-run it. The Rive data-binding runtime is accessed off the main thread (via Promise.async / the JS thread) without synchronization, corrupting the native heap. #298 fixed only the Java listener-map ConcurrentModificationException, not the underlying off-thread native access. Related: #297 / #298.

Reproduction

• Page: example/src/reproducers/Issue297ThreadRace.tsx (toggleable concurrent access).
• Run the Android harness under stress; reproduces ~1-in-10. Confirm on iOS under TSan (rn-harness.config.mjs sets TSAN_OPTIONS halt_on_error=0) — 25 races observed previously.

Mitigation

• Serialize all Rive runtime access to a single thread (or add native locking) so data-binding reads/writes never run off-main concurrently.

Closing criterion (guard)

Native access is made thread-safe and a *.harness.tsx stress guard reproduces the old crash on an unfixed build / passes on the fixed one → move to ci-flake:resolved.

---

Tracked via CI Flake Triage. This issue is intentionally closed — it is a ledger entry, not open work.

[mfazekas]

• 2026-07-01 — `test-harness-android` (job failed, run cancelled at ~35m after 3/3 attempts) — https://github.com/rive-app/rive-nitro-react-native/actions/runs/28504019421 — PR feat(hooks): async instance creation via useViewModelInstance({ async: true }) #304 (`feat/use-viewmodel-instance-async`)

Failing tests: `tests/entry-databinding.harness.tsx` (bridge disconnected) and `tests/autoplay-false-trigger.harness.tsx` (signal 11 SIGSEGV). Two distinct native stacks in `librive-android.so`, both on the Rive CommandServer thread:

1. rive::DataBindContainer::updateDataBinds(bool) → StateMachineInstance::advance() → advanceAndApply() → CommandServer::processCommands() — null deref, fault addr 0x0 (SEGV_MAPERR)
2. rive::StateMachineInstance::StateMachineInstance() → ArtboardInstance::defaultStateMachine() → CommandServer::processCommands() (SEGV_ACCERR)

Consistent with the #297 off-main-thread data-binding access theory: data binding is mutated/read from JS while the CommandServer thread advances the state machine.

[mfazekas]

Theory refinement — this is the experimental (default) backend, not legacy

The crash stack is entirely in the Rive CommandQueue / CommandServer path (CommandQueueWithThread::startCommandServer → CommandServer::serveUntilDisconnect → processCommands → StateMachineInstance::advance → DataBindContainer::updateDataBinds). That path is the experimental Android backend, which is the default; the legacy backend is opt-in via USE_RIVE_LEGACY=true (android/build.gradle swaps in android/src/legacy/java).

Evidence it is experimental-only: in run https://github.com/rive-app/rive-nitro-react-native/actions/runs/28504019421 the split jobs behaved differently —

• test-harness-android (no flag → experimental/CommandServer) → crashed (SIGSEGV)
• test-harness-android-legacy (USE_RIVE_LEGACY=true) → passed

Mechanism (refined): the experimental backend runs a CommandServer on its own thread that advances the state machine and calls DataBindContainer::updateDataBinds() every frame. The HybridViewModel* accessors touch the same native data-bind / VM state off that thread with no synchronization — getValueAsync() / viewModelAsync() are Promise.async { … } on Dispatchers.Default, and set() mutates native state. An off-thread set() / VM-swap frees or nulls a data-bind pointer mid-updateDataBinds → null deref (fault addr 0x0); a remount-driven StateMachineInstance construction racing the advance loop → the second stack.

Repro status: first local attempt did NOT reproduce (14× targeted + 4× full-suite + a high-concurrency provocation test all green) — because it was built off main/a docs branch, which does not contain the experimental integration at all, so CommandServer was never exercised. Rebuilding on the PR #304 branch (feat/use-viewmodel-instance-async, experimental default) and re-running the provocation there. Will update with the outcome + repro steps.

[mfazekas]

Reproduction attempts log (incl. dead ends)

Recording everything tried, including the failures — especially the results that push back on the theory.

Attempt 1 — WRONG code path (dead end) ❌

Built + ran the harness off main/a docs branch (Rive Android 11.6.1). Ran:

• 14× the two CI-failing tests in isolation (entry-databinding + autoplay-false-trigger) → 14 pass, 0 crash
• 4× the full harness suite → 4 pass, 0 crash
• 1× a purpose-built high-concurrency provocation (flake-databinding-race.harness.tsx: 64-way off-main viewModelAsync/set() churn + frequent remounts against an autoPlay+dataBind view, 6s) → pass

Why it was a dead end: that tree does not contain the experimental CommandServer integration at all (no USE_RIVE_LEGACY split, no android/src/legacy). So CommandServer/updateDataBinds — the crashing code — was never even compiled in. All 19 green runs were meaningless. (Thanks to the reviewer for flagging that CommandServer is the experimental backend.)

Attempt 2 — CORRECT path, experimental backend (in progress)

Rebuilt on the PR #304 branch feat/use-viewmodel-instance-async with the experimental default backend (Rive Android 11.4.1; legacy is opt-in). Ran:

• 1× provocation on experimental → pass (no crash)
• 12× full suite on experimental (stop-on-crash) → still running; so far no CommandServer SIGSEGV. Note: some non-crash failures appeared (rive.harness.ts, viewmodel-properties.harness.ts, rivelog.harness.tsx) — these are ordinary assertion/setup failures, not the native crash; investigating separately / possibly local-env or interaction with the added provocation test.

What this denies (so far)

• It denies the assumption that the race is easy to provoke locally. Even on the correct experimental backend, aggressive concurrent off-main churn on a fast arm64 host has not tripped it. Plausible reasons: (a) the x86_64 google_apis CI emulator schedules the CommandServer vs JS/Dispatchers.Default threads differently, widening the window; (b) local resolves 11.4.1 while the CI failure was on a build using 11.6.1 — the exact race window may differ between runtime versions; (c) my provocation may not hit the precise interleaving.
• It does not refute the underlying data-race theory — the CI stack (updateDataBinds null-deref + StateMachineInstance ctor on the CommandServer thread) is unambiguous. It just means natural/loop reproduction is not enough; confirming it will likely need widening the window in native code (an artificial delay/yield inside CommandServer::processCommands / updateDataBinds via a local rive-android build, or a TSan build) rather than JS-side stress alone.

Will append the final 12× tally and, if it crashes, the exact stack + repro steps.

[mfazekas]

Final local repro tally — NOT reproduced (documented dead end)

Build / path	Runs	Native CommandServer crash
main/docs tree (no experimental integration — wrong path)	14 targeted + 4 full-suite + 1 provocation = 19	0
PR #304 experimental backend (Rive Android 11.4.1)	1 provocation + 12 full-suite = 13	0
Total	32	0

The 12× experimental full-suite loop ended pass=0 non_crash_fail=12 crash=0. The non_crash_fails were the same 3 deterministic assertion failures every run (rivelog → NitroModulesProxy.createHybrid…, viewmodel-properties → backend is undefined / enum asset mismatch, setValueAsync) — i.e. artifacts of a hand-built local debug variant with a Nitro registration/codegen mismatch, not the native crash and not flaky. Verified 0 crash signatures in those logs.

Conclusion: JS-side stress does not reproduce this locally, even on the correct experimental backend on a fast arm64 host — 32 runs, 0 crashes. This denies the working assumption that concurrent off-main churn alone would trip it here; the race window on arm64 apparently stays closed. It does not refute the data-race theory (the CI stack is unambiguous).

Next step to actually confirm the theory (not yet done): widen the window in native code rather than from JS —

• add a deliberate sched_yield()/sleep inside CommandServer::processCommands / DataBindContainer::updateDataBinds in a local rive-android build, then run the provocation, or
• run a TSan/HWASan Android build (like the iOS TSan path) so the race is flagged on access rather than needing a lucky segfault.

[mfazekas]

Binding-level finding — scalar VM accessors call rive-android directly off-thread (do NOT go through the CommandQueue)

Looked at the experimental binding (android/src/new/java/com/margelo/nitro/rive/) on feat/use-viewmodel-instance-async:

• HybridViewModelInstance holds a CommandQueue riveWorker, but the scalar property accessors (numberProperty/stringProperty/booleanProperty/colorProperty/enumProperty/triggerProperty) are created without it — only image/list/artboard get riveWorker.
• HybridViewModelNumberProperty.set() → instance.setNumber(path, …); getValueAsync() → Promise.async { instance.getNumberFlow(path).first() } (i.e. on Dispatchers.Default). Same shape for the other scalars and even HybridViewModelListProperty (instance.getListSize(path) via runBlocking/Promise.async).
• riveWorker.* is only used for surface / state-machine / asset ops (createRiveSurface, createDefaultStateMachine, unregisterImage, …) — not for VM property get/set. Child VM binding uses ViewModelInstance.fromFile(file, source) directly; getPropertiesAsync calls file.getViewModelProperties(name) off-thread.

So our binding calls app.rive.ViewModelInstance methods directly from a background thread and never explicitly enqueues them onto the CommandQueue worker. Thread-safety therefore depends entirely on whether rive-android’s ViewModelInstance.setNumber / getNumberFlow / fromFile marshal onto the worker internally.

This reframes the theory (per the reviewer’s point that "CommandServer is there so any-thread calls get marshaled to the worker"): if that contract held for VM methods, there’d be no race. The crash in DataBindContainer::updateDataBinds says a VM mutation on Dispatchers.Default is not serialized against the worker’s advance/updateDataBinds — i.e. either rive-android’s VM instance/property methods are not CommandQueue-routed, or those objects aren’t worker-owned. That boundary lives in the rive-android SDK (AAR), not here → escalating to a rive-android-side investigation (audit VM method marshaling + inject a delay in CommandServer::processCommands/updateDataBinds to force the window).

[mfazekas]

Wrote a self-contained hand-off brief for a rive-android investigation: docs/rive-android-databinding-crash.md (env, both exact stacks + signal-code reading, the CommandQueue/CommandServer architecture, the RN binding-level finding, key questions, deterministic-repro recipe via a native delay / TSan, and the provocation harness inline).

Note on mechanism: the two faults have different signal codes — Stack A is SEGV_ACCERR at a real heap address (0x7708277d6960) = use-after-free / dangling pointer; Stack B is SEGV_MAPERR at 0x0 = null deref. Both fit one thread freeing/replacing an object (artboard / state machine / VM instance / data-bind) — e.g. on RiveView remount or an off-thread VM swap — while the CommandServer worker is still advancing it. Treating this primarily as a UAF/lifetime race, not just a null deref.

[mfazekas]

✅ Root cause found (rive-android investigation) — it is a runtime UAF fixed in 11.6.1

Not a cross-thread data race. It is a single-threaded re-entrancy / iterator-invalidation use-after-free inside rive::DataBindContainer::updateDataBinds, in the rive-runtime shipped with rive-android 11.4.1 (what PR #304 pins). Fixed in rive-android 11.6.1 — rive-runtime PR #12649 (999da28f).

The off-main-thread theory was a red herring (on Android)

In the experimental backend app.rive.ViewModelInstance.setNumber → CommandQueue.setViewModelInstanceNumber enqueues a command under a mutex onto the CommandServer worker; it never touches rive:: objects on the caller thread. So calling VM methods from Dispatchers.Default is safe by design on Android — which is exactly why arm64 JS-stress never reproduced it. (The RN binding’s "scalar accessors don’t hold riveWorker" observation is real but not the cause here.)

The actual bug (matches Stack B)

updateDataBinds() iterates m_persistingDataBinds with a range-for while calling each bind’s update(). When a bind auto-binds a nested view model, update() re-enters the same container via addDataBind() (→ push_back → vector realloc) or removeDataBind() (→ erase) → the active iterator is invalidated → heap-UAF:

rive::DataBindContainer::updateDataBinds(bool)+295   <-- Stack B
rive::StateMachineInstance::advance → advanceAndApply → CommandServer::processCommands

Stack A (UAF constructing a StateMachineInstance) is a sibling VMI/artboard lifetime issue, also fixed before 11.6.1 (rive-runtime #12561, 25682229).

Affected versions

rive-android	fixed?
11.4.1 (PR #304) / 11.5.0 / 11.6.0	❌ vulnerable
11.6.1 (wrapper main) / 11.7.0+	✅ fixed

This explains the repro table cleanly: our 0-crash runs were on trees pinning 11.6.1 (already fixed); the crash is on #304 = 11.4.1 (vulnerable). The arm64 non-repro was content/graph-dependent (needs a nested re-bind during advance), not a lucky thread interleaving. rive-android added a deterministic AddressSanitizer reproducer (dev/databind-reentry-repro/) that replays the exact frame.

Fix

Bump runtimeVersions.android → 11.6.1 on the #304 branch. PR incoming (will link). Signature stays ci-flake:active until that bump merges, then → ci-flake:resolved (guard = the version pin ≥ 11.6.1 + the upstream ASan regression test).

[mfazekas]

Fix PR: #312 (base: feat/use-viewmodel-instance-async) — bumps runtimeVersions.android 11.4.1 → 11.6.1. Verified the experimental backend builds clean against 11.6.1 (no API changes). Keeping this ci-flake:active until #312 merges, then flipping to ci-flake:resolved (guard = version pin ≥ 11.6.1).

[mfazekas]

Branch topology clarified: the experimental CommandQueue backend (android/src/new) was never merged to main — main is the pre-experimental stable line and already pins the fixed 11.6.1. The crash lives only on the experimental line, which pinned 11.4.1 and was never bumped.

Fix PRs (both bump runtimeVersions.android 11.4.1 → 11.6.1, build-verified against the experimental backend):

• fix(android): bump rive-android to 11.6.1 (fixes data-binding UAF crash) #313 → base feat/rive-ios-experimental (the upstream experimental line)
• fix(android): bump rive-android to 11.6.1 (fixes data-binding UAF crash) #312 → base feat/use-viewmodel-instance-async (feat(hooks): async instance creation via useViewModelInstance({ async: true }) #304, derives from the experimental line)

main needs no PR (already 11.6.1 and does not carry the experimental backend). This signature flips to ci-flake:resolved once the experimental line lands 11.6.1.