[Impeller][GLES] ImageDecoderImpeller SIGABRT persists on Flutter 3.44.8 across Android 10 Mali devices #190640

Activity

1. suryaKommana2662

   added

   in triagePresently being triaged by the triage teamPresently being triaged by the triage team

   on Aug 6, 2026
2. suryaKommana2662 commented on Aug 6, 2026

   

   suryaKommana2662

   on Aug 6, 2026

   Contributor

   More actions

   @dfdgsdfg Thanks for the detailed follow-up report and for confirming that the issue persists on Flutter 3.44.8 with updated production evidence. The report contains a symbolicated native stack, updated engine revision information, affected device/GPU details, and production data demonstrating that the crash continues to occur in the Impeller GLES image upload path. Routing this to the team-engine for further investigation.
3. suryaKommana2662

   added

   platform-androidAndroid applications specificallyAndroid applications specifically

   e: impellerImpeller rendering backend issues and features requestsImpeller rendering backend issues and features requests

   team-engineOwned by Engine teamOwned by Engine team

   and removed

   in triagePresently being triaged by the triage teamPresently being triaged by the triage team

   on Aug 6, 2026
4. FelixMittermeier commented on Aug 7, 2026

   

   FelixMittermeier

   on Aug 7, 2026

   Contributor

   More actions

   @dfdgsdfg Not sure if you saw it, but I created a PR with a likely fix for this issue yesterday. Could you please test if the issue no longer happens if you build the engine from my PR's branch? Thanks

   👀React with 👀1Reacted by seunggi
5. gaaclarke commented on Aug 10, 2026

   

   gaaclarke

   on Aug 10, 2026

   Member

   More actions

   The stacktrace unfortunately isn't helpful. Without a reproduction this is going to be difficult to address. @FelixMittermeier posted a draft PR that attempts to fix this. It would be an interesting datapoint to test. Unfortunately if we don't have a reproduction, we can't really know if it fixes it though.

   👀React with 👀1Reacted by seunggi
6. gaaclarke

   added

   needs repro infoAutomated crash report whose cause isn't yet knownAutomated crash report whose cause isn't yet known

   waiting for responseThe Flutter team cannot make further progress on this issue until the original reporter respondsThe Flutter team cannot make further progress on this issue until the original reporter responds

   P2Important issues not at the top of the work listImportant issues not at the top of the work list

   triaged-engineTriaged by Engine teamTriaged by Engine team

   on Aug 10, 2026
7. FelixMittermeier commented on Aug 27, 2026

   

   FelixMittermeier

   on Aug 27, 2026

   Contributor

   More actions

   @dfdgsdfg Is there any update on this topic? Do you have exact stacktrace or did you test if the change from the linked PR fixes the issue?
8. dfdgsdfg commented on Aug 27, 2026

   

   dfdgsdfg

   on Aug 27, 2026

   ContributorAuthor

   More actions

   Thanks for following up. I'm currently working on a reproducible demo. Since I don't have access to any of the affected physical devices, my plan is to first reproduce the issue with our actual app on a target device using Firebase Test Lab, and then reduce it to a minimal reproducible sample app.

   This is taking longer than I expected, so I haven't yet been able to reliably test whether the linked PR fixes the issue. The exact symbolicated stack trace currently available is the one included in the issue description. I'll share an update as soon as I have either a reproducible case or test results from the PR.
9. github-actions

   removed

   waiting for responseThe Flutter team cannot make further progress on this issue until the original reporter respondsThe Flutter team cannot make further progress on this issue until the original reporter responds

   on Aug 27, 2026
10. dfdgsdfg commented on Sep 2, 2026

    

    dfdgsdfg

    on Sep 2, 2026

    Last edited by dfdgsdfg

    ContributorAuthor

    More actions

    Update: I now have a deterministic physical-device reproduction and a candidate engine workaround. The evidence below is self-contained and does not require access to the Test Lab project. The full sanitized evidence is public in docs/evidence.md.

    @FelixMittermeier

    Reproduction

    The public reproducer is https://github.com/dfdgsdfg/mali-crash-app. Scenario 9 fixes the app source and arguments, device, renderer, and duration:

    • Physical Samsung Galaxy S9 (starlte), Android 10 / API 29, Mali-G72
    • Impeller with OpenGLES
    • 606-second game-loop test

    Only the embedded Flutter engine variant changes. The stock and diagnostic variants abort within about ten seconds in BlitPassGLES; the force-rebind variant completes.

    Confirmed failure signature

    The deterministic run ends in the same engine-side FML_CHECK/SIGABRT signature:

    signal 6 (SIGABRT), code -1 (SI_QUEUE), fault addr --------
    Abort message: '[FATAL:flutter/impeller/renderer/backend/gles/blit_pass_gles.cc(88)] Check failed: result. Must be able to encode GL commands without error.
    Break on 'ImpellerValidationBreak' to inspect point of failure: Could not create a complete framebuffer: GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT
    Fatal signal 6 (SIGABRT), code -1 (SI_QUEUE)
    

    The previously Build-ID-matched production symbolization confirms the major native path:

    fml::LogMessage::~LogMessage()
    impeller::BlitPassGLES::EncodeCommands() const::$_0
    impeller::ReactorGLES::React()
    flutter::ImageDecoderImpeller::UnsafeUploadTextureToPrivate()
    

    No Dart or app-owned plugin frame appears in that stack.

    Confirmed GL chronology

    This concise sanitized excerpt follows the failing GL name 7; context and thread identities are redacted:

    TextureTrace stage=initialize.bind logical_handle=209 gl_name=7 target=3553 thread=<redacted> raw_error_group=operation raw_error=GL_NO_ERROR(0) is_texture=true raw_error_group=is_texture_query raw_error=GL_NO_ERROR(0)
    TextureTrace stage=initialize.tex_image_2d logical_handle=209 gl_name=7 target=3553 thread=<redacted> raw_error_group=operation raw_error=GL_NO_ERROR(0) is_texture=true raw_error_group=is_texture_query raw_error=GL_NO_ERROR(0)
    TextureTrace stage=attachment.framebuffer_texture_2d.after logical_handle=209 gl_name=7 target=36009 textarget=3553 thread=<redacted> raw_error_group=operation raw_error=GL_NO_ERROR(0) is_texture=true raw_error_group=is_texture_query raw_error=GL_NO_ERROR(0)
    TextureTrace stage=texture.delete.after logical_handle=209 gl_name=7 thread=<redacted> raw_error_group=delete raw_error=GL_NO_ERROR(0) is_texture=false raw_error_group=is_texture_query raw_error=GL_NO_ERROR(0)
    TextureTrace stage=texture.generated logical_handle=unassigned gl_name=7 thread=<redacted> note=glIsTexture_may_be_false_before_first_bind
    TextureTrace stage=upload.tex_sub_image_2d logical_handle=215 gl_name=7 target=3553 thread=<redacted> raw_error_group=operation raw_error=GL_NO_ERROR(0) is_texture=false raw_error_group=is_texture_query raw_error=GL_NO_ERROR(0)
    TextureTrace stage=attachment.framebuffer_texture_2d.after logical_handle=215 gl_name=7 target=36008 textarget=3553 thread=<redacted> raw_error_group=operation raw_error=GL_INVALID_OPERATION(1282) is_texture=false raw_error_group=is_texture_query raw_error=GL_NO_ERROR(0)
    ConfigureFBO role=read/source fbo=1 status=GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT
    

    Confirmed sequence:

    1. The resource/offscreen context successfully binds, materializes, and attaches logical_handle=209, GL name 7.
    2. The shared renderer context sees name 7 as a valid texture and deletes that logical texture.
    3. glGenTextures returns numeric name 7 again for logical_handle=215. A false glIsTexture result immediately after generation can be normal before the first successful bind.
    4. Its upload reports GL_NO_ERROR, but glIsTexture(7) remains false.
    5. The first isolated GL error is GL_INVALID_OPERATION from FramebufferTexture2D; the read FBO then has GL_FRAMEBUFFER_INCOMPLETE_MISSING_ATTACHMENT, leading to the abort.

    The resource-context eglMakeCurrent succeeded, expected and actual EGL state matched, and the offscreen-created texture was visible from the renderer context.

    Inferred mechanism

    This is an inference from the trace and A/B, not a confirmed driver-internal fact: the deleted object may remain bound in the resource context after its numeric name becomes reusable. If Mali treats BindTexture(target, 7) as no state transition because that context still reports binding name 7, the newly generated name may never become a new texture object.

    The candidate workaround forces an explicit transition:

    BindTexture(target, 0);
    BindTexture(target, name);

    The passing trace repeatedly exercises numeric-name recycling. One representative successful reuse of name 7 records:

    TextureTrace stage=texture.delete.after logical_handle=175 gl_name=7 thread=<redacted> raw_error_group=delete raw_error=GL_NO_ERROR(0) is_texture=false raw_error_group=is_texture_query raw_error=GL_NO_ERROR(0)
    TextureTrace stage=texture.generated logical_handle=unassigned gl_name=7 thread=<redacted> note=glIsTexture_may_be_false_before_first_bind
    TextureTrace stage=upload.tex_sub_image_2d logical_handle=213 gl_name=7 target=3553 thread=<redacted> raw_error_group=operation raw_error=GL_NO_ERROR(0) is_texture=true raw_error_group=is_texture_query raw_error=GL_NO_ERROR(0)
    TextureTrace stage=attachment.framebuffer_texture_2d.after logical_handle=213 gl_name=7 target=36008 textarget=3553 thread=<redacted> raw_error_group=operation raw_error=GL_NO_ERROR(0) is_texture=true raw_error_group=is_texture_query raw_error=GL_NO_ERROR(0)
    

    A/B result

    The Flutter 3.44.8-based force-rebind diagnostic engine passed 4/4 physical runs, each for 606 seconds:

    Run	Iterations	Resize probes
    1	33,860	2,148 / 2,148
    2	33,397	2,148 / 2,148
    3	33,338	2,149 / 2,149
    4	33,436	2,148 / 2,148

    Across all four logs there were no observed GL_INVALID_OPERATION, ConfigureFBO failure, upload/attachment is_texture=false, or fatal/SIGABRT events.

    The minimal current-master patch is #192158. The physical A/B used the equivalent workaround on a Flutter 3.44.8-based diagnostic engine. PR #192158 ports it to current master; the current-master patch has host unit-test validation but has not itself been packaged for this physical run.

    This does not supersede #190655. That PR addresses a different failed-eglMakeCurrent lifecycle path. eglMakeCurrent succeeds in this reproduction, so this run does not exercise that condition. I have not directly tested #190655 and am not claiming that it fails to address other cases.

    Limitations: the deterministic A/B currently covers one device/driver combination, and the workaround adds one GL bind to each direct buffer-to-texture upload. Broader driver coverage and feedback on the performance/scope trade-off would be useful.

    I can provide raw logcats, result JSON files, exact engine/APK hashes, or additional sanitized excerpts if helpful.
11. FelixMittermeier commented on Sep 3, 2026

    

    FelixMittermeier

    on Sep 3, 2026

    Contributor

    More actions

    Great that you found a way to reproduce and fix it. I closed my initial PR because it really did not solve this specific issue.

    I am just wondering if this new extra call is needed all the time or just in special cases. Maybe there are performance impacts if there is now an additional call?

    However I think it makes more sense to tag @gaaclarke instead of me at this point. I am not part of the flutter team so I can't review your PR.

    👍React with 👍1Reacted by seunggi
12. marcuschanws commented on Sep 16, 2026

    

    marcuschanws

    on Sep 16, 2026

    More actions

    Another data point for this, from a different vendor and a much newer Flutter. I do not have a symbolized stack, so I am adding it here rather than opening a separate issue — if maintainers read it as distinct I am happy to move it.

    Still present on Flutter 3.47.0 stable

    The newest report above is 3.44.8. We hit the same abort on:

    • Flutter 3.47.0 stable, framework 4cf2416426, engine 5f77625673, Dart 3.13.0
    • Renderer: Impeller default, on the GLES backend (Vulkan is not viable on this device)

    F/libc: Fatal signal 6 (SIGABRT), pid <app>
    Abort message: [FATAL:flutter/impeller/renderer/backend/gles/blit_pass_gles.cc(88)]
    Check failed: result. Must be able to encode GL commands without error.
    

    One abort signature across ~103k lines of logcat, so the check itself is unambiguous — but the native frames were not symbolized, so I can confirm blit_pass_gles.cc(88) and not the frame above it. I have no reduced reproduction to hand over either; it is intermittent.

    Widens the device boundary again — Huawei / Kirin

    The report above notes the cohort had already grown past Exynos to MediaTek, both Samsung. This one is neither:

    • Huawei Mate 10 Pro, BLA-L29
    • Android 10 / API 29
    • HiSilicon Kirin 970
    • Mali-G72
    • OpenGL ES 3.2

    So the common factor across all three reports is Mali + Android 10 + the GLES backend, rather than any one SoC vendor.

    What the app was doing

    It aborted in two places, and both are this app's busiest moments for the GPU:

    1. A camera preview with video recording running beside it (package:camera, CameraX).
    2. A screen that plays two clips side by side — one video_player, and one "flipbook": a few hundred JPEG frames read from disk, decoded through ui.instantiateImageCodec / Codec.getNextFrame(), and painted as RawImage at ~30 fps.

    The second one is worth flagging. It drives ImageDecoderImpeller::UploadTextureToPrivate hard and on a clock — a freshly decoded ui.Image uploaded every frame or two, for hundreds of frames in a row. If the upload path in the stack above is the right one, that shape of workload may provoke it far more readily than waiting for a production crash, because it is a texture upload per frame rather than one per screen.

    The app uses no FragmentProgram and no BackdropFilter, so #186186 is not what this is.

    The mitigation, and the reason for writing

    The same as yours: EnableImpeller=false in the manifest ends it — same build, same phone. That is what we have shipped.

    The reason for adding to this issue rather than quietly taking the workaround is that the workaround now prints a deprecation notice:

    [Action Required]: Impeller opt-out deprecated. These options are going to go
    away in an upcoming Flutter release. Remove the explicit opt-out. If you need
    to opt-out, please report a bug describing the issue.
    

    This is that bug report. The escape hatch that several of us are relying on for Android 10 Mali devices is scheduled to disappear, and as far as I can tell the underlying abort has not moved since #188472. Knowing whether the opt-out will outlive this issue — or what is meant to replace it for GLES-only devices — would be worth a great deal to anyone in this thread. It decides whether those devices stay supported at all.
13. dfdgsdfg commented on Sep 16, 2026

    

    dfdgsdfg

    on Sep 16, 2026

    ContributorAuthor

    More actions

    For reference, Arm has identified the driver erratum matching the API sequence in our deterministic reproduction:

    Arm errata EN_ID 1,792,661 — affects Bifrost and Valhall GPU drivers r17p0 through r23p0, and was fixed in r24p0.

    Arm's confirmation and affected driver range.

    Arm confirmed that binding texture zero before rebinding the desired texture name reliably avoids this issue. They also noted that some OEMs may have backported the fix to earlier driver releases; applications cannot detect those backports. This historical erratum will not be added to the current public errata document, which only covers r36p0 and later, so the forum reply provides the reference and tracking ID.

    This is Arm's corrected diagnosis: their earlier reply about general FBO-attachment synchronization concerned a different issue.

    The workaround is under review in #192158. The current patch targets native GLES Mali-G / Immortalis-G drivers in the r17–r23 range, with a conservative fallback when the driver version cannot be parsed.

    The affected range above is a driver-version boundary, not a Samsung/Exynos or Android-version boundary. However, the shared blit_pass_gles.cc abort signature alone does not establish that every report here has this cause. For additional devices, including the Huawei/Kirin report, the full runtime GL_VENDOR, GL_RENDERER, and GL_VERSION strings would help establish whether they fall within Arm's confirmed range.
14. pull

    added a commit that references this issue on Sep 23, 2026

    [Impeller][GLES] Rebind textures before buffer uploads (flutter#192158)

    ...

    0e352c9
15. dfdgsdfg

    closed this as completedon Sep 29, 2026
16. github-actions commented on Oct 13, 2026

    

    github-actionsBot

    on Oct 13, 2026 – with GitHub Actions

    More actions

    This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
17. github-actions

    locked as resolved and limited conversation to collaborators on Oct 13, 2026