Crash on Samsung Galaxy S24 (Xclipse 940) after successful LiteRT WebGPU delegate initialization using Gemma 3n Vision

[itQ4Y]

I am developing a Flutter application that performs on-device document analysis using Gemma 3n Vision through flutter_gemma and flutter_gemma_litertlm.

The application consistently crashes on a Samsung Galaxy S24 immediately after LiteRT successfully initializes the GPU/WebGPU delegate.

The crash occurs after LiteRT successfully initializes the GPU and creates the WebGPU environment.

The GPU is correctly detected as Samsung Xclipse 940 and LiteRT reports:

• Created WebGPU environment
• Created LiteRT GpuEnvironment
• Replacing 3326 out of 3326 node(s) with delegate (LITERT_WEBGPU)

Immediately afterwards the application terminates with:

Lost connection to device

The complete log is attached.

I believe this may be a LiteRT/WebGPU issue, but I'm reporting it here first because it is reproducible through flutter_gemma.

Regards,

Ed Lanen,

Independent SW developer
info@itQ4Y.nl

See added files for more info:

litert_gpu_crash_samsung_xclipse940.txt

Gemma 3n Vision crashes on Samsung Galaxy S24 (Xclipse 940) after successful WebGPU delegate initialization.pdf

[DenisovAV]

Hi @itQ4Y — thanks for the detailed log. This looks like the same class of issue as #324 (Mali-G710 hard-freeze on the WebGPU delegate): all nodes get replaced by LITERT_WEBGPU, then it crashes right after GpuEnvironment creation. Some mobile GPU drivers (Mali, and it looks like Samsung Xclipse 940 too) don't survive the WebGPU vision path.

Two things that would help confirm it:

1. Is text-only inference (no image) on GPU stable on the S24? If yes, it's specifically the vision path.
2. The full native crash log (adb logcat around the crash), not just the LiteRT delegate lines.

The workaround that resolved #324 was running vision on CPU while keeping text on GPU — the litertlm engine configures the vision backend separately. If text-only GPU is stable and only vision crashes, forcing vision to CPU should get you unblocked.

I don't have an Xclipse 940 to reproduce directly, so those two data points would help a lot. Keeping this open.

[itQ4Y]

Thanks for the quick response and for pointing me to issue #324.That's very helpful.I'll run both tests you suggested:Text-only inference on GPU.A full native adb logcat captured around the crash.I'll report the results back here as soon as possible.Thanks for keeping the issue open.Met vriendelijke groet, kind regardsEd Lanen -------- Oorspronkelijk bericht --------Van: Sasha Denisov ***@***.***> Datum: 02-07-2026 21:56 (GMT+01:00) Aan: DenisovAV/flutter_gemma ***@***.***> Cc: itQ4Y ***@***.***>, Mention ***@***.***> Onderwerp: Re: [DenisovAV/flutter_gemma] Crash on Samsung Galaxy S24 (Xclipse 940) after successful LiteRT WebGPU delegate initialization using Gemma 3n Vision (Issue #351) DenisovAV left a comment (DenisovAV/flutter_gemma#351) Hi @itQ4Y — thanks for the detailed log. This looks like the same class of issue as #324 (Mali-G710 hard-freeze on the WebGPU delegate): all nodes get replaced by LITERT_WEBGPU, then it crashes right after GpuEnvironment creation. Some mobile GPU drivers (Mali, and it looks like Samsung Xclipse 940 too) don't survive the WebGPU vision path. Two things that would help confirm it: Is text-only inference (no image) on GPU stable on the S24? If yes, it's specifically the vision path. The full native crash log (adb logcat around the crash), not just the LiteRT delegate lines. The workaround that resolved #324 was running vision on CPU while keeping text on GPU — the litertlm engine configures the vision backend separately. If text-only GPU is stable and only vision crashes, forcing vision to CPU should get you unblocked. I don't have an Xclipse 940 to reproduce directly, so those two data points would help a lot. Keeping this open. —Reply to this email directly, view it on GitHub, or unsubscribe.Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[itQ4Y]

I ran the text-only GPU test with supportImage: false and no Message.withImage call.

The code only sends:

Message(
text: 'Say hello in one short sentence.',
isUser: true,
)

However, the app still crashes after LiteRT initializes the GPU/WebGPU delegate.

The log still shows:

• Main backend constraint matched: GPU
• VisionExecutorSettings: Not set
• Samsung Xclipse 940 selected
• Created WebGPU environment
• Replacing 3326 out of 3326 nodes with LITERT_WEBGPU
• Lost connection to device

Although supportImage was set to false, the native log still appears to initialize the vision components (tf_lite_vision_encoder). I'm not sure whether this is expected behavior for Gemma 3n or whether the vision model is still being initialized even for text-only inference.

So on this S24 / Xclipse 940 device, even text-only GPU inference with this Gemma 3n .litertlm model appears unstable.

I've also attached the full native adb logcat captured around the crash.

xclipse940_full_crash_log.txt

[DenisovAV]

Thanks for running both tests — the text-only crash plus the LITERT_WEBGPU lines in the log actually point away from the vision path and at the same root cause as #324: the OpenCL loader isn't available, so the engine falls back to the WebGPU delegate, which the Xclipse 940 driver doesn't survive.

What flutter_gemma version are you on? The fix landed in flutter_gemma 1.2.1 (now 1.2.3): the plugin manifest now declares libOpenCL.so (plus libvndksupport.so and the vendor variants), which lets Android's android_load_sphal_library() load the vendor OpenCL ICD. With that, the engine takes the OpenCL path instead of the crashing WebGPU fallback — we verified exactly this on a Galaxy S24 (Xclipse 940) via Firebase Test Lab: no crash.

Could you upgrade to flutter_gemma: ^1.2.3 + flutter_gemma_litertlm: ^1.0.3, do a clean rebuild, and confirm the log now shows the OpenCL path (not LITERT_WEBGPU)? If you're already on ≥1.2.1 and still get the WebGPU fallback, tell me — then something in your app manifest may be stripping the declaration and we'll dig into that.

[itQ4Y]

Hi DenisoaAV,
I captured a continuous full adb logcat around the failure.

There is no Fatal signal, SIGSEGV, SIGABRT, or native tombstone for the app.

Instead, during Gemma 3n E4B Vision inference, the device enters severe memory pressure. Android's lmkd starts reclaiming and killing multiple processes:

• "min2x watermark is breached even after kill"
• repeated lowmemorykiller / lmkd reclaim events
• even visible and important processes are killed

Shortly afterwards, com.example.frontend disappears and Flutter reports:

Lost connection to device

This suggests that the current failure may be caused by extreme memory pressure/OOM during Vision inference on the Galaxy S24, rather than a direct native segmentation fault.

The model used is:
gemma-3n-E4B-it-int4.litertlm

Versions:

• Flutter 3.44.6
• Dart 3.12.2
• flutter_gemma 1.2.3
• flutter_gemma_litertlm 1.1.0

The OpenCL path is active.

I have attached the complete continuous adb logcat.

regards,

Ed

errors.txt

full_native_crash.txt

[itQ4Y]

One additional observation: after selecting the PNG, the app continues processing for approximately 4 seconds before the process disappears and Flutter reports "Lost connection to device". This suggests the failure occurs during active Vision inference rather than during file selection or initial model loading.

[DenisovAV]

Thanks Ed — this log is conclusive, and it's good news on the original bug. Your S24 is now taking the OpenCL path (gpu_environment.cc: Created OpenCL device → Created LiteRT GpuEnvironment), with no LITERT_WEBGPU node replacement anywhere in the log. So the crash this issue was filed for — the WebGPU-delegate crash on the Xclipse 940 — is resolved by the libOpenCL.so declaration in 1.2.1+ (now 1.2.3).

The new failure is a different class: not a native crash (there's no SIGSEGV or tombstone) but an out-of-memory kill. The log shows Android's lmkd at its critical watermark ("min2x watermark is breached even after kill", level 2), reaping dozens of background processes and finally killing your app itself — even though it was foreground (oom_score_adj 0, fg TOP). That only happens when the whole device is physically out of memory.

The cause is model size. gemma-3n-E4B-it-int4.litertlm is a full multimodal E4B build — from your own loader dump it's ~4.58 GB on disk (≈2.5 GB main transformer + ~1.56 GB embedders + a ~665 MB audio encoder + a ~150 MB vision encoder). On an 8 GB S24, once that's mmap'd and a vision prefill starts (KV cache + vision-encoder activations + OpenCL working buffers, on top of Flutter and Samsung's own services), there's no headroom left, so lmkd starts killing — including you. It dies on the first vision pass, not gradually, which is the signature of a one-shot OOM rather than a leak.

Recommendation: switch to Gemma 4 E2B. It's about half the size (~2.4 GB), still does vision (and audio), and is newer than 3n (adds thinking mode). It should fit the S24's budget with room to actually run the prefill:

https://huggingface.co/litert-community/gemma-4-E2B-it-litert-lm/resolve/main/gemma-4-E2B-it.litertlm

For a vision use case on the S24, E2B is the right fit.

Once you confirm E2B runs on the device I'll close this as resolved — the WebGPU crash it was filed for is fixed. Reopen if anything else turns up.

[itQ4Y]

Thanks, Denisov.

I really appreciate the time you took to analyze the logs and help track this down.

Your explanations were very clear and helped me understand what was actually happening.

I'm glad the original WebGPU issue is resolved. I'll switch to the Gemma 4 E2B model and test that next.

Thanks again for your excellent support and for maintaining this project!

Best regards,
Ed