Any RN app (stock `helloWorld` and `helloWorld-rn72` templates) crashes with SIGABRT in stem-init before JS executes — reproduces on VVD and physical hardware, survives full SDK reinstall

Vega Open Beta Bug Reports
, ,
1

:warning: Before you continue

Reviewed troubleshooting docs at developer.amazon.com/docs/vega/0.24/troubleshoot-overview and its linked sub-pages (runtime-issues, kvd-issues, fire-tv-stick, sdk-install-issues, acr-issues) — none document this exact failure.

:backhand_index_pointing_right: Bug Description

1. Summary

SDK 0.24.x apps crash with a native SIGABRT in stem-init/liblcm_client within ~200-300ms of launch, before any JS executes — reproduces with completely unmodified helloWorld (RN 0.83) and helloWorld-rn72 (RN 0.72) templates, on both the Vega Virtual Device and physical hardware, across a full clean SDK reinstall. No app can currently be run or tested on this environment.

App Name: Streem (in-development; also reproduced independently with Amazon’s own unmodified helloWorld/helloWorld-rn72 templates) App Link on Amazon Appstore: N/A — not yet submitted/published, pre-release local development only

Bug Severity: :check_box_with_check: Blocks current development

2. Steps to Reproduce

  1. source ~/vega/env (SDK 0.24.12112 or 0.24.12044, both reproduce this)
  2. vega project generate --template helloWorld --name Test --packageId com.test.app --outputDir ./test (or helloWorld-rn72 — both templates reproduce identically)
  3. cd test && npm install
  4. vega build -t aarch64 -b Release (for VVD) or -t armv7 -b Release (for a physical Fire TV Stick 4K Select)
  5. vega virtual-device start (if targeting VVD)
  6. vega run-app <built-vpkg-path> com.test.app.main -d <VirtualDevice|physical-device-id> — CLI reports “Successfully launched the app”
  7. Wait ~3-4 seconds, then vega device is-app-running --appName com.test.app.main -d <device> → reports not running
  8. vega device get-log-info -d <device> → shows a new SYSTEM_TOMBSTONE/acr entry; vega device copy-logs --artifact SYSTEM_TOMBSTONE/acr --directory <dir> -d <device> to retrieve it

No custom component or method call is involved — this reproduces with zero custom code, using Amazon’s own generated template as-is.

3. Observed Behavior

The app process starts, then aborts with SIGABRT within ~200-300ms — before Hermes/React Native ever executes any JS (no UI ever renders, not even a blank/loading frame). vega device is-app-running confirms the process is gone seconds later. This is 100% reproducible, every launch attempt, across every combination of app/template/device we tried.

Crash backtrace (identical class of failure across both RN 0.83 and RN 0.72 apps — same subsystem, different internal offsets):

Thread 0 (crashed), reason: SIGABRT
libc.so.6 (abort) → libstdc++.so.6 (std::terminate chain) → liblcm_client.so.0 (multiple frames)
→ libasync.so.0 → libstem_init.so

4. Expected Behavior

The app should launch normally and render its UI, as with any other Vega SDK 0.24.x React Native app.

4.a Possible Root Cause & Temporary Workaround

No workaround found. What we ruled out through direct testing:

  • Not a manifest misconfiguration — reproduces with the SDK’s own unmodified, freshly-generated manifest.toml for both templates.
  • Not specific to the RN 0.83 runtime-module reference — RN 0.72’s completely different runtime-module(/com.amazon.kepler.keplerscript.runtime.loader_2@IKeplerScript_2_0 vs. RN 0.83’s /com.amazon.kepler.runtime.react_native_kepler_4@IReactNativeKepler_0) crashes in the identical subsystem.
  • Not a corrupted local SDK install — a full vega sdk uninstall/vega sdk install clean reinstall (39,000+ files) reproduced byte-for-byte identical crash offsets.
  • Not an OS-build-version mismatch — this is the most surprising finding: the VVD’s bundled image reports RELEASE_ID="21" (matching the leading digits of what the 0.24 release notes document as required, OS 1.2 (2101020054720)), while our physical Fire TV Stick 4K Select reports RELEASE_ID="23" (a newer/different track, BUILD_DATE="Thu Sep 10 22:05:50 UTC 2026" vs. VVD’s "Fri Sep 18 21:35:23 UTC 2026") — yet both crash identically, which argues against OS version being the differentiator at all.
  • Not a build/bundling config issue — vega exec vpt dump <vpkg> assets/raw/keplerscript-app-config.json looks structurally normal for both our app and the vanilla templates.
  • Core LCM services appear otherwise healthy — com.amazon.lcm.app-control-ops.service is actively serving many other successful requests in the same log window our app crashes.

Similar in class to this earlier report and to a documented VVD issue in kvd-issues (“Module dependency not found… upgrade SDK to 0.22+, or test on physical Fire TV instead”) — but neither’s fix applies here (we’re past 0.22+, and physical hardware crashes identically).

5. Logs or crash report

Have full ACR/tombstone files for multiple crashes (VVD and physical device, RN 0.83 and RN 0.72 apps) — cannot attach here (“Sorry, new users can not upload attachments.”). Can provide main/var_log/system/var_log captures on request.

696# — our app (Streem), physical device:

Process:com.streemmedia.streem.vega
CrashReason:SIGABRT
CrashTimeUTC:1790477406000
OsBuildNumber:2301020004820
SystemVersion:4.0.476660.0(3072cab629675a74)/48N:user/release-keys

Thread 0 (crashed)
 0  libc.so.6 + 0x21b26
 1  libc.so.6 + 0x5e2af
 2  libc.so.6 + 0x2fc91
 3  libc.so.6 + 0x21613
 4  libstdc++.so.6 + 0x80435
 5  libstdc++.so.6 + 0x7ecf3
 6  libstdc++.so.6 + 0x7ed55
 7  libstdc++.so.6 + 0x7efb9
 8  liblcm_client.so.0 + 0x7ca4d
 9  liblcm_client.so.0 + 0x7d67d
 10  liblcm_client.so.0 + 0x7d57f
 11  liblcm_client.so.0 + 0x975e9
 12  liblcm_client.so.0 + 0xbf14d
 13  liblcm_client.so.0 + 0x92689
 14  liblcm_client.so.0 + 0x92cc9
 15  liblcm_client.so.0 + 0x93713
 16  libappfwkutils_async.so.0 + 0xbea3
 17  libappfwkutils_async.so.0 + 0xdfaf
 18  libappfwkutils_async.so.0 + 0xa893
 19  libasync.so.0 + 0x4e29
 20  libstem_init.so + 0x910c3
 21  libstem_init.so + 0x97b39

698# — vanilla helloWorld (RN 0.83), physical device, SDK 0.24.12044: identical backtrace to 696# above (byte-for-byte same offsets) — worth noting inline as “same offsets as our own app’s crash.”

4# — vanilla helloWorld-rn72 (RN 0.72), Vega Virtual Device:

Process:com.test.hellorn72
CrashReason:SIGABRT
CrashTimeUTC:1790478809000
OsBuildNumber:2111248248030
SystemVersion:1.0.228248.0(9a1d8dfa7da5d600)/102282480N:user/dev-keys

Thread 0 (crashed)
 0  libc.so.6 + 0x81d98
 1  libc.so.6 + 0x3de4e
 2  libc.so.6 + 0x2b062
 3  libstdc++.so.6 + 0xa4762
 4  libstdc++.so.6 + 0xa20fe
 5  libstdc++.so.6 + 0xa2182
 6  libstdc++.so.6 + 0xa24d2
 7  liblcm_client.so.0 + 0x3cd6e
 8  liblcm_client.so.0 + 0x4d1b2
 9  liblcm_client.so.0 + 0x3d1ce
 10  liblcm_client.so.0 + 0x9456e
 11  liblcm_client.so.0 + 0x94e7a
 12  liblcm_client.so.0 + 0x5a6d6
 13  liblcm_client.so.0 + 0x5e39a
 14  libasync.so.0 + 0x6a9a
 15  libasync.so.0 + 0x8d1a
 16  libstem_init.so + 0xb044e
 17  libstem_init.so + 0xb8d7a
 18  libstem_init.so + 0xb327a
 19  libstem_init.so + 0xb327a

6. Environment

  • SDK Version: vega --version → Active SDK Version: 0.24.12112, Vega CLI Version: 1.4.2 (also reproduced on SDK 0.24.12044)

  • React Native Version: Both RN 0.83 and RN 0.72 (reproduces on both)

  • App State: Foreground (crash happens during initial launch, before any foreground/background transition is possible)

  • OS Information (cat /etc/os-release):

    Physical Fire TV Stick 4K Select:

    NAME="OS"
OS_VERSION="1.2"
BRANCH_CODE="TV Ship"
BUILD_DESC="OS 1.2 (TV Ship/48)"
BUILD_FINGERPRINT="4.0.476660.0(3072cab629675a74)/48N:user/release-keys"
BUILD_VARIANT="user"
BUILD_TAGS="release-keys"
BUILD_DATE="Thu Sep 10 22:05:50 UTC 2026"
VERSION_NUMBER="2301020004820"

    Vega Virtual Device (Apple Silicon):

    NAME="OS"
OS_VERSION="1.2"
BRANCH_CODE="TV Ship"
BUILD_DESC="OS 1.2 (TV Ship/102282480)"
BUILD_FINGERPRINT="1.0.228248.0(9a1d8dfa7da5d600)/102282480N:user/dev-keys"
BUILD_VARIANT="user"
BUILD_TAGS="dev-keys"
BUILD_DATE="Fri Sep 18 21:35:23 UTC 2026"
VERSION_NUMBER="2111248248030"

7. Example Code Snippet / Screenshots / Screengrabs

N/A — reproduces with zero custom code, using Amazon’s own vega project generate --template helloWorld (and helloWorld-rn72) output unmodified.

:backhand_index_pointing_right: Playback Issues

N/A — not a playback issue.

:backhand_index_pointing_right: Additional Context

The physical device installed a system update the same day we hit this (no change to BUILD_DATE/VERSION_NUMBERobserved after). We’re not certain whether this is a regression from a recent SDK/OS release or a longer-standing issue — RN 0.83 support is documented as “early access” in the 0.24 release notes, and we separately found an unresolved forum thread about WebView apps breaking after an OS update with a different symptom (an ANR from a missing RN$SurfaceRegistry, not a SIGABRT) — not the same bug, but showing RN runtime compatibility has had ongoing churn through mid-2026.

3

Update: found the real root cause — this was not an SDK bug, retracting the report.

Sorry for the noise. The actual cause: vega build -t armv7 -b Release (the command used throughout this report, and shown in Amazon’s own build docs) was silently producing a package missing the compiled JS bundle. Switching to npx react-native build-vega --build-type Release --target armv7 (going through the React Native CLI wrapper instead of the vega CLI’s own build orchestration) produces a correctly-bundled package, and both the stock templates and our own app now install, launch, and run stably on the same physical device where every vega build-produced package crashed with the SIGABRT described above.

For anyone else who hits this exact signature (SIGABRT in stem-init/liblcm_client within ~250ms of launch, before any JS executes): check whether your .vpkg’s size looks suspiciously small for what your app should contain, and try building via react-native build-vega instead of vega build directly.

Thanks to everyone who might have looked at this — apologies again for the false alarm.