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.

8

Hi @Jackson_Yarger,

Welcome to Amazon Developer Community!!

Thanks for the exceptionally thorough write-up - and for coming back to post the root cause and the fix.

One quick ask to help us fix the source of the confusion: you mentioned vega build -t armv7 -b Release was “shown in Amazon’s own build docs.” Could you share the exact URL(s) of the page(s) you followed? The published Version Your App pages (0.24 and 0.23) currently show react-native build-vega, so we’d like to pin down precisely where the vega build guidance came from so we can get it corrected.

Warm regards,
Ivy