[Android] SIGABRT "pthread_mutex_lock called on a destroyed mutex" at engine teardown — reproduces across both Adreno/Vulkan and Mali/GLES #193182

Reporting production crash data for the FORTIFY: pthread_mutex_lock called on a destroyed mutex family, because we appear to have something the existing reports are missing: the same abort on two different GPU vendors using two different graphics APIs, with tombstones and lifecycle breadcrumbs.

Related: #192047 (closed, waiting for response), #190195, #118094, #85196.

Environment

Flutter 3.44.6 (stable)
Engine  d3a3293399556a85388faf8c6f0723a7a5597aa8 (revision 83675ed276, 2026-06-30)
Dart    3.12.2
Impeller: default (no io.flutter.embedding.android.EnableImpeller meta-data present)
Build: release, R8 enabled, split APKs via Play App Signing

Plugins that touch rendering or background isolates:

home_widget                 0.9.3
workmanager                 0.10.7
sentry_flutter              9.24.0   (NDK + Tombstone integrations enabled)
google_mobile_ads           9.0.0
flutter_local_notifications 22.3.1

The crash is not vendor-specific

A — Qualcomm Adreno, Vulkan. App main thread, inside Looper::pollOnce:

__fortify_fatal                              libc
HandleUsingDestroyedMutex                    libc
pthread_mutex_lock                           libc
<3 obfuscated frames>                        vulkan.adreno.so
qglinternal::vkDestroyFramebuffer            vulkan.adreno.so
<12 frames>                                  libflutter.so
android::Looper::pollOnce                    libutils.so
android.os.MessageQueue.nextLegacy           (boot.oat)
android.app.ActivityThread.main

B — ARM Mali, OpenGL ES. A driver-internal thread named mali-cmar-backe, with no Flutter frames at all:

__start_thread / __pthread_start             libc
<4 frames>                                   libGLES_mali.so
pthread_mutex_lock                           libc
HandleUsingDestroyedMutex                    libc
__fortify_fatal / abort                      libc

Same libc abort path, different vendor, different API, and in (B) the faulting thread belongs to the driver rather than to Flutter — consistent with a driver worker outliving the context that created it.

Lifecycle: it happens at teardown, not during use

Breadcrumbs from case (A), relative to session start. The whole teardown is 562 ms:

+51.286s  MainActivity paused
+51.824s  onTrimMemory / LOW_MEMORY (level 40)
+51.836s  MainActivity stopped
+51.848s  MainActivity destroyed
+51.990s  app lifecycle -> background
          (abort)

The 38 seconds before that are idle — no navigation, no user interaction. The memory-trim and the activity destroy land inside the same half-second, so the engine is releasing GPU resources while the activity is being torn down.

Note for anyone correlating timestamps: these arrive via Android tombstones, and the event timestamp is when the tombstone was collected on the next launch, not when the crash happened. In case (A) the breadcrumbs end at 18:37 UTC and the event is stamped 01:22 UTC — a 6.75 h gap.

Spread

8 crashes, 8 distinct users, 6 device models, 2 GPU families, Android 15 and 16:

All installs from Play, none sideloaded, none rooted.

Not tied to one app version. First seen on our build 2056 (14 Sep), still present on 2063 — same engine across both.

One thing about our app that may be relevant

We render Flutter widgets offscreen to a bitmap from short-lived background isolates, more often than a typical app: HomeWidget.renderFlutterWidget() is called from a WorkManager callback and from a widget-interaction callback, to repaint an Android home-screen widget. Each of those spins up an engine, rasterises on the GPU, and shuts down.

We have not proved this is the trigger — in case (A) the nearest widget render is 44 s before the abort — but it is the one thing we do that most apps do not, and it creates GPU contexts outside the normal Activity lifecycle. Flagging it in case it narrows the search.

What we can provide

Full symbolicated tombstones, complete breadcrumb trails, and device/OS tags for all 8 events. Happy to attach whatever is useful. We cannot reproduce on demand — all 8 are from the field.

We are aware EnableImpeller=false is deprecated (#190195), and in any case it would not address the Mali/GLES case above.