Debug builds (including the helloWorld template) abort with SIGABRT after ~480 s on screen — Fire TV Stick 4K Select

Vega Open Beta Bug Reports
1

Summary

On a physical Fire TV Stick 4K Select, Debug builds are killed by a native SIGABRT on the JS thread after about 480 seconds on screen — including the helloWorld template generated by vega project generate, changed only by a 10-second console.log heartbeat. In our own app the faulting frame is libkeplerscript-runtime-loader-4.so.4.0 + 0x6f11b; eight crash reports share one descriptor, and
the template’s abort carries the same crash fingerprint, JSThread_6_7b15f81b1886a2eb9790d0dc39fd1c44. Release builds of our app have not aborted in three runs of 13, 21 and 21 minutes.

The timer appears to count foreground time only: when the app is sent to the launcher and resumed on the same process, process lifetime at death grows by the time spent away, while the platform’s own PackageScreenTime at death stays at about 478 s.

We also report two intermittent SIGSEGV families below. One of them occurs when the app leaves the foreground, and we have not been able to establish whether it affects Release.

Environment
Device Fire TV Stick 4K Select (callie, model AFTCA002), armv7l
OS Vega OS 1.2 (TV Ship/48)
Build fingerprint 4.0.476660.0(3072cab629675a74)/48N:user/release-keys
Vega SDK 0.24.9914
Vega CLI 1.3.4
React Native 0.83.0
@amazon-devices/react-native-kepler 4.0.1+rn0.83.0
React 19.2.0
Runtime module /com.amazon.kepler.runtime.react_native_kepler_4@IReactNativeKepler_0
launch-type singleton
Connection Wi-Fi, device addressed as <ip>:5555
App id com.outfit.chalkboard, component com.outfit.chalkboard.main

Minimal reproduction

  1. vega project generate -t helloWorld -n abortrepro --packageId com.example.abortrepro -o <dir>

  2. npm install

  3. Optional, for a positive control only: append to index.js

    const REPRO_T0 = Date.now();
setInterval(() => {
  console.log(`ABORTREPRO heartbeat ${Math.round((Date.now() - REPRO_T0) / 1000)}s`);
}, 10000);

    This renders nothing and touches no state; it only lets you confirm over the Hermes CDP target that the JS runtime is executing. (These lines did not appear in start-log-stream for the template, although our own app’s console output does. The template calls LogBox.ignoreAllLogs(); we have not established whether that is the reason.)

  4. npx react-native build-vega --build-type Debug --target armv7, start Metro, and reverse-forward 8081 and 8097 to the device.

  5. vega device install-app --directory . --buildType Debug -d <ip>:5555, then
    vega device launch-app --appName com.example.abortrepro.main -d <ip>:5555, and leave it.

Result on 2026-09-16: launched 15:56:28 UTC, PID 16482, heartbeat confirmed over CDP through at least 100 s. At 16:04:28 UTC — 480 s after launch — the log stream shows:

ACR_BEGIN COMM:JSThread SIG:6 PID:16482 …
Creating crash file …_16482_6_com_example_abortrepro.acr
  with Descriptor: 7c3fab4af96ca801af21afdb507fd9bc
  with Fingerprint: JSThread_6_7b15f81b1886a2eb9790d0dc39fd1c44
metric report for com.example.abortrepro PackageScreenTime/DeviceTime: 476 477

The descriptor differs from our app’s (29d0d920…) but the fingerprint is identical; we assume the descriptor includes the package. Vault report 53, MemAvailable: 424928 kB, CrashReason: SIGABRT.

Steps to reproduce in our app

  1. Build Debug for armv7: npx react-native build-vega --build-type Debug --target armv7.
  2. Install and launch on the device:
    vega device install-app --directory . --buildType Debug -d <ip>:5555, then
    vega device launch-app --appName <component> -d <ip>:5555.
  3. Leave the app in the foreground with no input. (To keep the ambient screensaver away on long runs we injected one D-pad key at launch; input does not change the result — runs with many key presses and runs with none abort at the same foreground time.)
  4. After roughly eight minutes the app disappears. ACR_BEGIN … SIG:6 appears in
    vega device start-log-stream, and the report is retrievable with
    vega device copy-logs -a SYSTEM_TOMBSTONE/acr.

Expected: the app keeps running.
Actual: native abort at 477–482 s of foreground, every time.

Evidence

The crash

ACR_BEGIN COMM:JSThread SIG:6 PID:<pid> … P:!usr!bin!stem-init
Creating crash file …_6_REDACTED.acr
  with Descriptor: 29d0d920397f09cfc91aa6b5e92355a9
  with Fingerprint: JSThread_6_7b15f81b1886a2eb9790d0dc39fd1c44

Faulting frame: libkeplerscript-runtime-loader-4.so.4.0 + 0x6f11b. The fingerprint above was logged for every one of these reports we captured live (35, 36, 43, 45); the vault files themselves do not contain it.

Report Crash time (UTC) Descriptor
26 2026-09-15 02:19:35 29d0d920…
27 2026-09-15 02:35:11 29d0d920…
30 2026-09-15 02:54:09 29d0d920…
31 2026-09-15 03:05:23 29d0d920… (9 s after a Fast Refresh; not counted as clean)
35 2026-09-16 01:02:44 29d0d920…
36 2026-09-16 01:25:05 29d0d920…
43 2026-09-16 02:09:29 29d0d920…
45 2026-09-16 13:04:34 29d0d920…

At each abort the app was VISIBLE and in the foreground. In all eight reports LCM_KILLREASON is present but empty, and MemAvailable was between 344 MB and 471 MB.

It counts foreground time

The platform logs PackageScreenTime/DeviceTime for the process at the abort:

Report Time away from the foreground DeviceTime at abort PackageScreenTime at abort
45 none 480 477
43 none 478 477
35 ~24 s (one Home → return, same PID confirmed) 503 479
36 ~25 s (two Home → return, same PID confirmed) 505 480

Process lifetime at the abort grows by the time spent on the launcher; screen time does not. Reports 26 and 27 aborted at 502 s and 500 s of wall-clock time, and both launches sat NOT_VISIBLE behind the screensaver for ~24 s before being brought forward — consistent with ~477 s of foreground.

What we have ruled out

  • Network and rendering load. One abort (report 45) occurred on schedule while the app was stuck on a loading screen, making no network requests and rendering no content.
  • The Metro / Fast Refresh connection. We launched Debug, confirmed the bundle had loaded and the CDP target was live, then stopped Metro 51 s in. The app aborted with SIGABRT 479 s after launch (report 51). That report carries a different descriptor, ee84acd0e9b0f81f77956dab34a18a53, with libkeplerscript-4.so.4 prominent in the module list — same signal, same timing, different stack. We note it without drawing a conclusion from one sample.
  • Release builds. Three Release runs survived 780 s, 1,264 s and 1,276 s. Each was confirmed executing throughout by MountingManager::SurfaceTelemetryLogger output every 5 s up to the end of the run, with no crash report. (Our Release build points at a host that is not yet deployed, so it was failing its API requests rather than polling; given that report 45 aborted with no requests at all, we do not believe this explains the difference.)

What we have not established

  • Whether the Vega Virtual Device is affected. Our attempt was inconclusive and we are not reporting a result for it.
  • The mechanism, and whether the foreground counter is cumulative since launch or reset on resume. The same-process runs above fit “cumulative since launch”.
  • Symbolication. symbolicate_acr in the Amazon Devices Builder Tools MCP fails on these reports (see “Related tooling issues”).

Two further crash families

Both are native SIGSEGVs and distinct from the abort above.

Descriptor Thread Reports Context
5dd254ea17f149b411c5ef618422ab32 TimerThread 25, 40 a few seconds after a Fast Refresh, both times
ee4e7cf9e986f676a2c61a3421695e80 Toolkit!UI 37, 42 on leaving the foreground

For ee4e7cf9…:

  • Report 37: 0.3 s after lcm-server: Screensaver watchdog: idle but no screensaver visible, launching os:/…. In vlcm list the instance afterwards showed STOPPED with no container.
  • Report 42: 79 s after the app was sent to the launcher with the Home key, while backgrounded. A later vmsgr send pkg://… then cold-started a new process rather than resuming.
  • It is intermittent: the app has resumed on the same PID after at least five other Home and screensaver transitions.
  • We have not backgrounded a Release build, so we do not know whether this family affects Release. This is the one we are most concerned about, since backgrounding is ordinary use.

A third SIGABRT descriptor, 8a05090b1386b5beb07a7171b207e289 (reports 21, 23, 24), occurred before we were timing runs and is not characterised.

Related tooling issues

  1. symbolicate_acr fails (decodeMode: gdb) with
    Failed to copy …/temp_acr_debugFs/acr_libraries.txt to <ip>:5555, and the same with the device serial. A direct vega device copy-to of a small file to the same device succeeds, so this is not
    the Wi-Fi connection.
  2. vega device copy-to --help labels --source as “on the device” and --destination as “on the host”; the command actually pushes from the host to the device.
  3. vega device reboot reboots the device but exits 253 with Cannot read properties of undefined (reading 'trim').
  4. vega device launch-app without --appName prints the help text and launches nothing, which can look like a failed launch.
  5. vmsgr send pkg://<component> resumes a live instance but silently cold-starts if the instance has died, which makes it easy to mistake a new process for a resumed one.

What would help us

  • Whether this is a known issue in the Debug runtime on this OS build, and whether it is fixed in a later SDK or OS.
  • A symbolicated stack for 29d0d920… and ee4e7cf9….
  • Whether ee4e7cf9… can occur in Release builds.
  • Guidance on a working symbolication route for third-party developers.
4

Hi @michaelfromtheoutfit,

Thank you for an exceptionally thorough report - the eight ACR descriptors sharing the
JSThread_6_7b15f81b1886a2eb9790d0dc39fd1c44 fingerprint, the foreground-vs-wall-clock timing analysis (PackageScreenTime ~477s vs process lifetime growing with time on the launcher), and the Debug-vs-Release comparison are extremely helpful for narrowing this down.

What we tried: We ran the helloWorld template (RN 0.83.0, SDK 0.24.9914, CLI 1.3.4 — matching your setup) as a Debug build for ~10 minutes of foreground time and did not reproduce the ~480s abort — no SIG:6, no ACR. But we ran on the Vega Virtual Device (aarch64), not your armv7 Fire TV Stick 4K Select. Since the faulting frame is in the native libkeplerscript-runtime-loader-4, this points to the issue being specific to armv7/your OS build rather than app code. We’re pursuing an armv7 repro internally.

Could you share the 29d0d920… and ee4e7cf9… ACRs? We’ll symbolicate them on our end. If the forum blocks attachments, paste the dump sections inline or link a doc.

On symbolication: the symbolicate_acr MCP copy failure is a transport issue, not your Wi-Fi. Use Vega Studio instead - right-click the ACR → Symbolicate ACR (or command palette → Copy ACR from device → Symbolicate ACR), choose the gdb decode type, and select Debug rootfs if the device pull fails. Docs: Symbolicate App Crash Reports - Amazon Vega Docs and Fix Crash Analysis Issues - Amazon Vega Docs

Also useful: Detect Where the App Crash Originates - Amazon Vega Docs (attribute the frame to app vs Amazon code) and AI Assisted Crash Analysis - Amazon Vega Docs .

We’re investigating and will update soon.

Thanks for helping us improve the Vega platform.

Best regards,
Aishwarya

5

Hi Aishwarya,

Thank you — this is very helpful, and the Vega Studio symbolication route is exactly what we were missing. We’ll try it and report back with what we find.

The forum doesn’t allow attachments, so the crash reports are here: https://drive.google.com/file/d/1PPZsPnKCBPFC97Cqo0nW6I9ttLpAwtkC/view?usp=sharing

It’s a single zip (4 MB) with a README. Every .acr is exactly as vega device copy-logs -a SYSTEM_TOMBSTONE/acr returned it, renamed only, including its core dump section:

  • sigabrt-29d0d920/ — Stick reports 26, 27, 30, 31, 35, 36, 43, 45, 55, 56 (the ~480 s Debug abort; 31 followed a Fast Refresh, so treat it as confounded)
  • sigsegv-ee4e7cf9/ — Stick reports 37 and 42 (Debug, UI thread, on leaving the foreground)
  • template-repro-armv7/ — Stick report 53, the helloWorld template’s ~480 s abort (descriptor 7c3fab4a…)
  • release-install-over/ — six Release reports for a separate crash we’ve now characterised; see point 3

Two corrections, then a new, reproducible crash.

  1. The fingerprint doesn’t identify the stack. The ten abort reports share the descriptor 29d0d920…; the fingerprint JSThread_6_7b15f81b1886a2eb9790d0dc39fd1c44 was captured in the live log for six of them. We’ve since seen the same 7b15f81b… suffix on every UI-thread SIGSEGV below (Toolkit-UI_11_7b15f81b…), so we now read the fingerprint as encoding only thread and signal. Our case that the template abort is the same fault rests on the same thread, the same signal and the same ~480 s on screen — not on a fingerprint match.

  2. Your Virtual Device result fits ours. The template abort (report 53) was on the Stick (armv7, OS 1.2, build fingerprint 4.0.476660.0(3072cab629675a74)/48N:user/release-keys, model AFTCA002). We never completed a clean Debug soak on the Virtual Device ourselves, so your ten-minute negative is the best data point there.

  3. New, and reproducible on both architectures: installing a build over a running Release app crashes the old instance if that instance has been to the launcher and back.

We ran an install-over matrix with vega device install-app on a running Release build, reading the crash vault before and after every case:

State of the running app when the new build is installed Virtual Device (aarch64) Stick (armv7)
Freshly launched, no trip to the launcher 0 / 12 0 / 5
After one Home → return trip, on screen 3 / 3 3 / 3
After one trip, then backgrounded again 1 / 2 2 / 2
After one trip, then vega device terminate-app first 0 / 2 0 / 2
helloWorld template, after one trip, on screen 2 / 2 2 / 2
  • Every crash is a native SIGSEGV on the UI thread (live-log fingerprint Toolkit-UI_11_7b15f81b…). Descriptors: 4385c93f… (our app, Stick), dbbc2818… (our app, Virtual Device), 78047a2f… (template, Stick), ab7a01f7… (template, Virtual Device).
  • The template crashes the same way, so we believe this is platform-side rather than in our app.
  • The trigger appears to be replacing a process whose surface has been destroyed and recreated by a trip to the launcher (the surface ID moves from 1 to 11 on return in our logs). terminate-app first avoids it in every case we ran.
  • Question: does an Appstore update applied to an app that is open or in the background take this same path? If so, any app that has been visited, sent Home and then updated would log this crash.
  • One Virtual Device report (45) carries a CRASH_DATE about ten hours off; the Virtual Device’s clock appears to be wrong, so please don’t rely on its timestamps.
  • In release-install-over/: one from our app and one template rlus the two earlier sightings (Stick report 54, Virtual Device report 45). We have more of each and are happy to share them.

Thanks again for picking this up so quickly.

Best,

Michael Witwicki