Title: SIGABRT / std::terminate in VideoPlayer.deinitialize* when exiting clear HLS playback on Back (Callie)
Bug Description
1. Summary
Native crash (SIGABRT / std::terminate) in the Kepler / W3C media runtime when leaving an HLS playback screen via Back. The process dies during VideoPlayer teardown (deinitialize / deinitializeSync, also seen as deinitializeAsync in logs) and relaunches. Reproduces on one Callie device; other Callie on our side cannot reproduce.
App Name: TabloTV
App Link on Amazon Appstore: https://www.amazon.com/gp/product/B0GPZLB146
Bug Severity:
Impacts operation of app
2. Steps to Reproduce
- Install the app on an affected Callie device (see Environment).
- Launch the app (foreground).
- Start clear HLS (m3u8) playback via headless W3C
VideoPlayer+ Shaka (no DRM / no AES-128). - Wait until playback reaches
playing(a few seconds). - Press Back to leave the player screen.
APIs / components involved:
@amazon-devices/kepler-player-client/@amazon-devices/kepler-player-server(headless)@amazon-devices/react-native-w3cmediaVideoPlayer- Teardown via
IPlayerClient.unloadSync→ serverhandleUnloadSync→VideoPlayer.deinitializeSync/deinitialize
3. Observed Behavior
- After Back, logs show unload / Shaka unload / surface clear, then
deinitializeSync/deinitializeAsync. - Process aborts with native SIGABRT; app logs stop mid-deinit.
- A new process starts shortly after (
KeplerApplication::init). - ACR GDB symbolication stops at:
raise() → abort() → std::terminate()
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
- ACR has
FullUnwind: false; unwind does not continue paststd::terminate/libkeplerscript-runtime-loader.
4. Expected Behavior
Back should finish media teardown and return to the previous screen without killing the process. VideoPlayer deinitialize / unloadSync should complete for clear HLS.
4.a Possible Root Cause & Temporary Workaround
Suspected: Uncaught C++ exception / abort inside Amazon native media teardown (VideoPlayer.deinitialize*) on some OS/device builds when exiting HLS. Similar crash site to the community report for AES-128 HLS deinit; our content is clear HLS (empty DRM scheme / license URI). Same API, not confirmed same root cause.
Tried:
- Call
unloadSyncwhile the surface is still mounted (before navigate/unmount); serialize unload; guard against double unload — still crashed on the affected device. - Soft unload (skip
deinitialize*): pause/mute + Shaka unload + clearSurface — avoids the abort on Back on the affected device, but then second playback can fail (HW decoder / caps negotiation), so that is only a partial workaround.
5. Logs or crash report
Attach:
-
Crash Report (ACR):
crash.acr (700.4 KB)
6. Environment
SDK Version: [paste vega --version]
Relevant deps (approx.):
@amazon-devices/react-native-w3cmedia:^2.2.21@amazon-devices/kepler-player-client/kepler-player-server:^2.2.11@amazon-devices/react-native-kepler:^2.0.9000000000
App State: Foreground (active / foreground activities true in ACR)
OS Information (affected device at crash):
NAME=“OS”
OE_VERSION=“4.0.0”
OS_MAJOR_VERSION=“1”
OS_MINOR_VERSION=“2”
RELEASE_ID=“21”
OS_VERSION=“1.2”
BRANCH_CODE=“TV Ship”
BUILD_DESC=“OS 1.2 (TV Ship/547)”
BUILD_FINGERPRINT=“4.0.378951.0(3072cab629675a74)/547N:user/release-keys”
BUILD_VARIANT=“user”
BUILD_TAGS=“release-keys”
VERSION_NUMBER=“2101020054720”
Device: Callie, armhf / armv7
Note: Same app build does not crash on another Callie in our lab (different stick / possibly different OS image).
a stick where it is working is:
NAME=“OS”
OE_VERSION=“4.0.0”
OS_MAJOR_VERSION=“1”
OS_MINOR_VERSION=“1”
RELEASE_ID=“14”
OS_VERSION=“1.1”
BRANCH_CODE=“TV Ship day60”
BUILD_DESC=“OS 1.1 (TV Ship day60/99)”
BUILD_FINGERPRINT=“4.0.227617.0(3072cab629675a74)/99N:user-external/release-keys”
BUILD_VARIANT=“user-external”
BUILD_TAGS=“release-keys”
BUILD_DATE=“Tue Feb 17 22:57:51 UTC 2026”
BUILD_TIMESTAMP=“1771369071”
VERSION_NUMBER=“1401010009950”
Reproduces on one Callie; does not on another Callie in our lab on OS 1.1. The affected device also reproduced on OS 1.1 before updating to OS 1.2 (VERSION_NUMBER=2101020054720 / BUILD_FINGERPRINT=…/547N:user/…). So this does not appear limited to the 1.2 image alone.
7. Example Code Snippet
Simplified headless teardown:
// UI (Back): sync unload while surface may still be mounted
client.unloadSync(5000, sessionId);// Headless handler
handleUnloadSync(timeoutMsec) {
// pause/mute → player unload → clearSurfaceHandle
// → VideoPlayer.deinitializeSync(timeoutMsec) // crash observed here
}
Playback uses Shaka attached to a headless VideoPlayer, not in-UI MSE.
Playback Issues
Clear HLS (m3u8). Architecture: armv7.
Player SDK: Shaka Player (Vega compiled bundle)
Player SDK Version: 4.8.5
Audio Codecs: AAC (AC-3 on some streams)
Video Codecs: H.264
Manifest Types: m3u8
Q: media/content url
Private / dynamically issued stream URL — can share a redacted sample or private link with Amazon on request.
Q: special headers?
No DRM license headers.
Additional Context
- 3P GDB symbolication of the ACR always ends at
std::terminate()with incomplete unwind (FullUnwind: false). - Soft-unload without
deinitialize*avoids the abort but breaks reliable second start (decoder / caps). Looking for guidance on a safe teardown that neither aborts nor leaves the HW decoder unusable. - Happy to provide additional ACRs and paired
loggingctlcaptures.