Repository navigation
[Android] GIF image loading causes file descriptor leak (FD count grows indefinitely) only when images are visible on screen #186899
Description
Steps to reproduce
When loading and displaying GIF images on Android, the number of open file descriptors (FD) increases indefinitely and never gets released, eventually causing the app to become unresponsive or crash due to FD exhaustion.
Important finding: The FD leak only occurs when GIF images are actually visible on screen. When GIFs are scrolled off-screen or the widget is unmounted, the FD count does NOT increase. This suggests the leak is related to active decoding/rendering of GIF frames, not just caching or loading.
This issue started occurring in Flutter 3.41.x and persists in 3.44.0. The same code works perfectly in Flutter 3.38.10.
1.Create a simple Flutter app that loads GIF images (e.g., using Image.network or Image.asset)
2.Keep the GIFs visible on screen (e.g., in a ListView without scrolling, or a PageView)
3.Monitor FD count using /proc/self/fd
4.Observe FD count continuously increasing while GIFs are visible
5.Scroll the GIFs off-screen or navigate away — FD growth stops
Expected results
FD count should remain stable regardless of whether GIFs are visible on screen.
Actual results
GIFs visible on screen → FD count grows indefinitely
GIFs not visible (scrolled off-screen / disposed) → FD count remains stable
Eventually FD limit is reached (typically 1024-4096), causing app to slow down and crash
Code sample
Code sample
import 'package:flutter/material.dart';
void main() => runApp(MyApp());
class MyApp extends StatelessWidget {
@override
Widget build(BuildContext context) {
return MaterialApp(
home: Scaffold(
appBar: AppBar(title: Text('GIF FD Leak Test')),
body: ListView.builder(
itemCount: 20,
itemBuilder: (context, index) => Image.network(
'https://example.com/animated.gif', // Any GIF URL
height: 300,
),
),
),
);
}
}FD Monitoring Code (Kotlin)
Add this to MyApplication.kt:
Code sample
Handler(Looper.getMainLooper()).post(object : Runnable {
override fun run() {
val fdCount = File("/proc/self/fd").listFiles()?.size ?: 0
Log.d("FD_Monitor", "Current FD count: $fdCount")
Handler(Looper.getMainLooper()).postDelayed(this, 2000)
}
})Screenshots or Video
Screenshots / Video demonstration
[Upload media here]
Logs
// With GIFs VISIBLE on screen:
Logs
D/FD_Monitor: Current FD count: 247
D/FD_Monitor: Current FD count: 312
D/FD_Monitor: Current FD count: 389
D/FD_Monitor: Current FD count: 451
D/FD_Monitor: Current FD count: 523
D/FD_Monitor: Current FD count: 598
... (continues growing until crash)// After scrolling GIFs OFF screen:
Logs
D/FD_Monitor: Current FD count: 598
D/FD_Monitor: Current FD count: 599
D/FD_Monitor: Current FD count: 598
D/FD_Monitor: Current FD count: 597
... (stable, no further growth)Flutter Doctor output
Doctor output
[✓] Flutter (Channel stable, 3.41.6)
[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
[✓] Xcode (Version 15.4)
[✓] VS Code (version 1.89.1)
[✓] Connected device (1 available)
Activity
m7yun commentedon May 21, 2026
Additional Context
Platform: Android only (iOS works fine)
Android versions tested: 12, 13, 14
Devices tested: Pixel, Xiaomi, Samsung
Image format: GIF only (PNG, JPEG, WebP work fine)
Leak condition: Only when GIF is actively being rendered on screen
Not a caching issue: cached_network_image_ce does not solve it
Possible Root Cause
Based on the "visible only" behavior, the leak likely occurs in the on-screen rendering pipeline for animated GIFs, specifically:
The frame decoder may be opening file descriptors per frame/animation cycle
These FDs are not being closed when frames are rendered
The issue was likely introduced by changes to ImageDecoder or SkCodec between Flutter 3.38.10 and 3.41.0
Request
Please investigate the GIF decoding and frame rendering implementation in the Android engine layer, with special attention to:
File descriptor lifecycle during active GIF animation
Differences in lib/ui/painting/image_decoder.cc between versions 3.38.10 and 3.41.0
Whether SkCodec or ImageDecoder is properly closing resources after each frame
Thank you!
mbcorona commentedon May 22, 2026
Thanks for the report. I tried to reproduce this on Flutter 3.44.0 (the version you say still affects this) on a physical Android device, using a real GIF in the same ListView setup you described. I monitored the FD count via run-as for over 20 minutes with the GIFs visible.
The FD count stayed stable between 150 and 202 the whole time — no growth, no approach to any limit. It actually went down over time as the initial network sockets closed.
A few things that would help us investigate further:
Could you share a runnable repro with a real GIF URL (not the example.com placeholder), ideally as a GitHub repo or gist?
Your flutter doctor shows 3.41.6 but the report mentions 3.44.0 — did you actually test on 3.44.0? It didn't reproduce there for me.
Could you also share full flutter doctor -v output, the device model, and whether your real app uses plugins that might open FDs on their own (networking, video, audio, camera, etc.)? Your starting FD count of 247 is already higher than what I see on a baseline Flutter app, so something in your setup may be contributing.
m7yun commentedon May 22, 2026
Hello,
After my testing, I found that this FD leak issue occurs when loading GIF images inside a ListView component. It happens with both the standard ListView and ListView.builder.
Key observations:
The FD count only increases when GIF images are visible on screen
When I scroll up until all GIF images move off the visible area, the FD count stabilizes and stops growing
Please note that my project only loads GIFs inside ListView. I have not tested other scrolling components such as GridView or SingleChildScrollView.
You can reproduce this issue using the following sample code:
Code sample
Log Output
With GIFs VISIBLE on screen
After scrolling GIFs OFF screen
Flutter Doctor output
Doctor output
jason-simmons commentedon May 23, 2026
Reproduced this using the app from #186899 (comment) and the Impeller/GLES back end.
The app is displaying an animated WebP image that loops infinitely, so the engine is continuously creating
TextureGLESinstances. The file descriptor leak happens because some of those textures are leaking their GL fence sync objects.Normally if a fence has been set on a
TextureGLES, then it will be deleted whenTextureGLES::Bindis called. But when the animated image creates frames nonstop, some of the resulting textures never get aBindcall. TheTextureGLESdestructor then does not clean up the fence.m7yun commentedon May 24, 2026
Thank you for your attention and detailed response.
I have verified that this issue only reproduces when Impeller is enabled. Running the app with flutter run --no-enable-impeller works fine without any FD leak.
May I ask what the estimated timeline is for a fix and an upcoming stable release?
Best regards.
[Impeller] Ensure that the TextureGLES destructor cleans up all objec…
[CP-stable][Impeller] Ensure that the TextureGLES destructor cleans u…
nay0958 commentedon Jun 19, 2026
I tested in flutter to show animated GIFs in chat list screen many format from .WEBM and .mp4 and .gif but it is so FD is leaking in second.But if you want to show without leaking FD ,the safety way is using Lottie.json format it can prevent from leaking FD to show animated GIFs view in chat screen
[Impeller] Ensure that the TextureGLES destructor cleans up all objec…
github-actions commentedon Jul 14, 2026
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 -vand a minimal reproduction of the issue.