SIGSEGV in libGLESv2_mtk.so on FCNT arrows We2 devices

[sebastian-gallese-speak]

Submission checklist

• Confirmed on the latest rive-android version — affected hardware unavailable
• Searched the documentation and forums
• Searched existing issues; no duplicate found

Description

Rendering a Rive animation causes a native SIGSEGV on these FCNT arrows We2 models:

• FCG02 — au/UQ
• A402FC — SoftBank
• F-52E — docomo

Crashlytics reports the same blame frame across the affected models:

SIGSEGV
libGLESv2_mtk.so + 0x119230

The crash occurs on Rive's render thread, with the native trace passing through librive-android.so and libEGL.

In our app, this occurs shortly after startup when the learning path renders a Rive animation. The process terminates, and the crash can recur after relaunch, preventing affected users from reaching lessons.

We have observed this crash signature with:

• Rive Android 11.7.1
• Rive Android 11.8.0

We have not tested the latest Rive version on affected FCNT hardware.

Previous working version

None known on the affected devices and current firmware.

Reproduction steps / code

We cannot reproduce this on an emulator or on other Android hardware.

Observed production sequence:

1. Launch the app on FCG02, A402FC, or F-52E running Android 16.
2. Navigate to—or restore directly into—a screen containing a Rive animation.
3. The process terminates with the native crash above as the animation begins rendering.

No specific .riv file has been identified as the trigger.

Rive Android runtime version

11.7.1 and 11.8.0

Rive API

Legacy (RiveAnimationView)

Device

• FCNT arrows We2 FCG02
• FCNT arrows We2 A402FC
• FCNT arrows We2 F-52E

Device OS

Android 16, ARM64

App minimum SDK level

API 26

App target SDK level

API 36

App NDK level

Not explicitly pinned

Other Rive runtimes affected

Unknown

Additional context

The corresponding current carrier firmware versions are:

• FCG02: V54RK51B
• A402FC: V54RS51B
• F-52E: V54RD51B

Crashlytics does not include the device build number, so we cannot confirm the installed firmware for each individual event.

[yokomii]

Same crash signature on the Compose runtime (11.8.0) — plus a code-level hypothesis

We're seeing this exact signature in production on a Japanese consumer app, on the same three FCNT arrows We2 models. Adding our data since our setup differs from the original report in ways that may help narrow it down.

What differs from the original report

• API: Compose runtime (Rive() / rememberRiveWorker / CommandQueue), not the legacy RiveAnimationView
• Version: 11.8.0
• arm64-v8a, minSdk 26 / targetSdk 36

Since the original report is Legacy on 11.7.1/11.8.0 and ours is Compose on 11.8.0, this does not appear to be specific to either API surface.

Our data

Devices	FCG02, A402FC, F-52E — and nothing else, 0 events on any other device
SoC	Mediatek MT6855 (Dimensity 7025) on all three — i.e. an IMG/PowerVR GPU, consistent with libIMGegl.so in the trace
Impact	19 users / 165 events
OS	All events on Android 16 (we can't tell whether these models exist on other OS versions in our user base)
First event	2026-08-24

Symbolized stack

Our trace resolves further into librive-android.so than the libGLESv2_mtk.so + 0x119230 blame frame in the original report — same offset in the driver:

#00 pc 0x119230  /vendor/lib64/egl/mt6855/libGLESv2_mtk.so
#01 pc 0x045c08  /vendor/lib64/mt6855/libIMGegl.so (IMGeglMakeCurrent+2536)
#02 pc 0x01cdb0  /system/lib64/libEGL.so (android::egl_display_t::makeCurrent(...)+176)
#03 pc 0x02613c  /system/lib64/libEGL.so (android::eglMakeCurrentImpl(void*, void*, void*, void*)+460)
#04 pc 0x3c3704  librive-android.so (rive_android::RenderContextGL::beginFrame(rive_android::RenderSurface*)+64)
#05 pc 0x3aaaec  librive-android.so
#06 pc 0x446e78  librive-android.so (rive::CommandServer::processCommands()+58680)
#07 pc 0x4388c8  librive-android.so (rive::CommandServer::serveUntilDisconnect()+56)
#08 pc 0x3a6abc  librive-android.so (CommandQueueWithThread::startCommandServer(...)::'lambda'()::operator()()+892)
#10 pc 0x082e6c  libc.so (__pthread_start(void*)+236)

Hypothesis: an unvalidated EGLSurface reaching eglMakeCurrent

In kotlin/src/main/cpp/src/models/render_context_gl.cpp, beginFrame passes the surface handle straight to the driver:

rive::gpu::RenderTarget* RenderContextGL::beginFrame(RenderSurface* surface)
{
    auto* glSurface = static_cast<RenderSurfaceGL*>(surface);
    auto eglSurface = glSurface->eglSurface();
    if (!eglMakeCurrent(eglDisplay, eglSurface, eglSurface, eglContext))

and RenderSurfaceGL only stores a raw handle (eglSurface() is just return m_surface;) with no validity tracking.

If a destroyed/invalidated EGLSurface can reach this call, a well-behaved driver returns EGL_BAD_SURFACE and Rive handles it safely (logs, returns nullptr). The IMG/PowerVR driver appears to segfault instead — which is exactly where these crashes land. A false return can be handled; a segfault inside the driver cannot, so the check would have to happen before the call — a validity check before eglMakeCurrent, or dropping queued draws for surfaces pending destruction.

Note that render_context_gl.cpp is unchanged from 11.7.2 through 11.10.0, so we are not suggesting this was introduced in 11.8.0 — we simply haven't investigated other versions and are only reporting what we observe on 11.8.0. One thing that did change in 11.8.0 is the Compose draw loop's settling model (StateMachineSettlingStore, plus extra unsettle triggers in Rive.kt — after the resize path, and a fresh unsettled generation when playing resumes). If that increases how often beginFrame runs right after surface changes, it would widen the window for racing surface teardown, but we have not verified that.

We're also unsure whether the lifetime work in 11.9.0 (Tighten lifetime contracts) and the RiveSurface / CommandQueue hardening through 11.10.0 covers this ordering — it looks adjacent, but beginFrame itself still passes the handle through unchecked.

Caveats on our own data

• Our first event (Aug 24) is after the Aug 17–18 carrier firmware updates listed in the original report, so we can't rule out a firmware component.
• Like the original reporter, we have no affected hardware and cannot reproduce.