SIGSEGV in libGLESv2_mtk.so on FCNT arrows We2 devices #468

Activity

1. yokomii commented on Sep 1, 2026

   

   yokomii

   on Sep 1, 2026

   More actions

   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.
2. yokomii commented on Sep 17, 2026

   

   yokomii

   on Sep 17, 2026

   More actions

   Update: we now have stronger evidence of a correlation with the August FCNT firmware rollout, plus confirmation that this signature also occurs with an older Rive runtime.

   We queried the Google Play Developer Reporting API across OS versions and combined three Android Vitals issue groups whose sample traces share these driver frames:

   libGLESv2_mtk.so + 0x119230
   libIMGegl.so (IMGeglMakeCurrent+2536)
   libEGL.so (android::egl_display_t::makeCurrent(...)+176)
   libEGL.so (android::eglMakeCurrentImpl(...)+460)
   

   Firmware rollout versus first observed occurrence

   The queried window was July 19 through September 17, 2026. Timestamps below are hourly buckets converted to JST, not exact event timestamps. Firmware versions are from the vendors' release notices, not from the crashing devices themselves.

   Device	Firmware rollout began	Released build	First observed matching crash (JST)
   A402FC / SoftBank	August 17	V54RS51B	August 20, 08:00–08:59
   FCG02 / au・UQ	August 18	V54RK51B	August 20, 20:00–20:59
   F-52E / docomo	August 24	V54RD51B	August 25, 07:00–07:59
   M07 / SIM-free	August 25	V54RM51B	September 4, 21:00–21:59

   Within this window, these three groups contain 1,096 crash reports, all on Android 16 and these four models. We found no occurrences in these groups before the corresponding model's firmware rollout date. This corrects the August 24 first-occurrence date in our earlier comment: the expanded query finds occurrences from August 20 JST. M07 is also an additional affected model.

   Evidence beyond timing alone

   • An older, unchanged app binary is affected. Our app 32.3.1, released in June, uses the legacy RiveAnimationView with Rive 11.6.1. It has 12 matching reports on FCG02, starting September 3 JST. The trace's native Build ID, d271de6a2790799dcd5fdbe29bd459ccc787a0cf, exactly matches the arm64 library in the published Rive 11.6.1 AAR. The Rive frames are PLSWorkerImpl::PLSWorkerImpl(...) → PLSThreadState::makeCurrent(void*), followed by the same driver frames above.
   • This is not just the devices first adopting Android 16. Historical Vitals usage data already includes FCG02 on Android 16 in March. On F-52E, the same app version that later crashed, 34.4.0, already had reported Android 16 usage during a full daily interval preceding the August 24 firmware rollout.
   • The signature persists across runtime versions. We also verified sample-trace Build IDs against the published Rive 11.7.2, 11.8.0 and 11.9.2 arm64 libraries. The 11.9.2 traces lack the earlier exported Rive function names, but the first four driver frames remain identical, so following only the older Vitals group would undercount the continuing issue.

   Interpretation and remaining gaps

   The staggered onset after each model's firmware rollout strengthens the hypothesis of a firmware/Rive OpenGL interaction. It does not establish that the firmware changed the GPU driver or prove a driver defect. The available API reports do not expose the installed firmware build, and the public update notes do not identify specific graphics-driver changes.

   Our earlier invalid/destroyed EGLSurface explanation remains an unverified hypothesis. The legacy trace also reaches eglMakeCurrent during worker construction, so the evidence does not establish a teardown-only failure.

   We still do not have affected hardware. Are there known compatibility issues with this FCNT firmware family, or specific EGL diagnostics / renderer workarounds you would recommend to distinguish a driver regression from a Rive context/surface lifecycle issue?

   👍React with 👍3Reacted by Keita Nakamura, loora-andreym and vegeta2102
3. vegeta2102 commented on Sep 24, 2026

   

   vegeta2102

   on Sep 24, 2026

   Last edited by vegeta2102

   More actions

   I face the same issue here. Any updates from dev team ?
4. ErikUggeldahl

   self-assigned this

   on Sep 25, 2026
5. ErikUggeldahl

   added

   bugSomething isn't workingSomething isn't working

   confirmedThe issue has been reproduced successfullyThe issue has been reproduced successfully

   on Sep 25, 2026
6. ErikUggeldahl

   added the

   Bug

   issue type on Sep 25, 2026
7. vegeta2102 commented on Sep 29, 2026

   

   vegeta2102

   on Sep 29, 2026

   Last edited by vegeta2102

   More actions

   @yokomii @sebastian-gallese-speak

   Could you please try setting the renderer type when initializing Rive for the MT6855 SoC?

   if (Build.SOC_MODEL.equals("MT6855", ignoreCase = true) )
    Rive.init(context.applicationContext, defaultRenderer = Rive.Canvas)
   else 
    Rive.init(context.applicationContext, defaultRenderer = Rive.Rive)

   (please also remove the <meta-data android:name="app.rive.runtime.kotlin.RiveInitializer" ... /> entry from the Android manifest if you're using this way)
8. ErikUggeldahl commented on Sep 29, 2026

   

   ErikUggeldahl

   on Sep 29, 2026

   Collaborator

   More actions

   @vegeta2102 We're attempting to solve this one, and we have independent reports from a couple enterprise clients. The issue appears to be only on a specific firmware from August. We have an appropriate device but are looking for options to get the firmware, as it's only OTA in Japan.

   Please be aware that the Canvas renderer only works in the legacy API, doesn't support some features such as vector feathering, and is deprecated.

   We'll continue to try to fix this for the new API.

   ❤️React with ❤️4Reacted by vegeta2102, yokomii, Yo-suke Kobayashi and Yuki Asano
9. amberkira commented on Oct 12, 2026

   

   amberkira

   on Oct 12, 2026

   More actions

   We encounter the same issue，all happened in FCNT.