[Android] Close FlutterRenderer texture image SyncFence objects immediately after waiting on them#188313
Conversation
There was a problem hiding this comment.
Code Review
This pull request refactors FlutterRenderer.java to use try-with-resources for SyncFence in waitOnFence to ensure it is closed, and adds a unit test to verify this behavior. The reviewer suggests refactoring the duplicated waitOnFence method from two inner classes into a single helper method in the outer class to improve maintainability.
| @RequiresApi(API_LEVELS.API_33) | ||
| private void waitOnFence(Image image) { | ||
| try { | ||
| SyncFence fence = image.getFence(); | ||
| try (SyncFence fence = image.getFence()) { | ||
| fence.awaitForever(); | ||
| } catch (IOException e) { | ||
| // Drop. |
There was a problem hiding this comment.
There is an identical implementation of waitOnFence(Image) at line 789. Since both containing classes are inner classes of FlutterRenderer, you can eliminate this duplication by moving waitOnFence to the outer FlutterRenderer class as a single package-private or private static helper method, and calling it from both inner classes.
References
- Suggest simplification and refactoring to enhance readability and maintainability, and avoid duplicating code/state where possible. (link)
…iately after waiting on them Each SyncFence may use a file descriptor. But the SyncFences were not being closed promptly and their file descriptors were not being deleted until the SyncFences were garbage collected. If the process is rendering video and creating a SyncFence for each frame, then it may run out of file descriptor capacity before Java GC happens. Fixes flutter#188161
1131850 to
aeae493
Compare
…iately after waiting on them (flutter#188313) Each SyncFence may use a file descriptor. But the SyncFences were not being closed promptly and their file descriptors were not being deleted until the SyncFences were garbage collected. If the process is rendering video and creating a SyncFence for each frame, then it may run out of file descriptor capacity before Java GC happens. Fixes flutter#188161
|
Requesting a cherry-pick of this fix to stable (3.44) — and, since the Impacted Users: Any app rendering sustained SurfaceProducer-backed Impact Description: One sync_file fd leaks per rendered frame; the process Production data from our fitness app (30-60 min workout sessions with looping
Workaround: None in-app; the leak is in the engine's Java embedding. We Risk: Low — the fix closes an AutoCloseable ( Test Coverage: Reproduction in #188161 (flutter_webrtc example, Pixel 6a); Validation Steps: Run any long video_player session on an Android 13+ |
Each SyncFence may use a file descriptor. But the SyncFences were not being closed promptly and their file descriptors were not being deleted until the SyncFences were garbage collected.
If the process is rendering video and creating a SyncFence for each frame, then it may run out of file descriptor capacity before Java GC happens.
Fixes #188161