Repository navigation
Description
Steps to reproduce
- Navigate to the demo directory with cd demo_win
- flutter pub get
- flutter run -d windows --release
- Navigate through the application: open the menu, select 'New Flutter Window', then close the Flutter Window.
- Repeat step 4 ten times. You will notice a consistent increase in memory usage.
Code sample
see the flutter example project
demo_win.zip
What target platforms are you seeing this bug on?
Windows
OS/Browser name and version | Device information
Windows 11 x64 13th Gen Intel(R) Core(TM) i7-13700KF 3.42 GHz
Does the problem occur on emulator/simulator as well as on physical devices?
Unknown
Logs
No response
Flutter Doctor output
[✓] Flutter (Channel stable, 3.16.0, on macOS 13.6.1 22G313 darwin-x64, locale zh-Hans-CN)
[!] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
✗ cmdline-tools component is missing
Run path/to/sdkmanager --install "cmdline-tools;latest"
See https://developer.android.com/studio/command-line for more details.
✗ Android license status unknown.
Run flutter doctor --android-licenses to accept the SDK licenses.
See https://flutter.dev/docs/get-started/install/macos#android-setup for more details.
[✓] Xcode - develop for iOS and macOS (Xcode 14.2)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2022.3)
[✓] VS Code (version 1.84.2)
[✓] Connected device (2 available)
[✓] Network resources


Activity
huycozy commentedon Nov 23, 2023
Hi @yaminet1024
The multi-window has not been supported yet so I'm unfortunately going to close this issue. Please follow #30701 for further updates. Thanks!
yaminet1024 commentedon Nov 24, 2023
@huycozy hi, I think this is not a issue related to multi-windows. This problem will also occur when a single window is opened and closed. The purpose of repeating it 10 times is to reflect the increase in memory. This is a desktop engine memory leak I think.
huycozy commentedon Nov 27, 2023
Re-opening the issue for further investigation.
I tried running the example on my Windows
Microsoft Windows [Version 10.0.19045.3693]but the issue didn't appear there. I observed app memory from Task Manager and noticed it consumed ~50MB every time openingNew Flutter Window(from 20MB to 70MB), and then it got back to 20MB after closingNew Flutter Window(tried this more than 10 times).On your machine, does the memory continue to increase the more times you try?
yaminet1024 commentedon Nov 27, 2023
Yes, I am very sure that there is a memory leak problem. As you can see from my screenshots, from 37.2 to 44.1, there will be an average leak of about 1m at a time. In our actual complex project, there will be 3m at a time.
11 remaining items
loic-sharma commentedon Dec 1, 2023
Thanks for reporting this! The leaks reproduce on my machine and are primarily allocations by ANGLE. However, our shutdown logic appears to be correctly tearing down the EGL contexts and display. I wonder if we're somehow not cleaning up properly, or, if ANGLE itself is leaking.
yaminet1024 commentedon Dec 2, 2023
I've been analyzing this issue and identified one problem: Flutter creates EGL contexts on the IO or raster thread but releases them on the platform thread. This does not correctly release the ANGLE thread; it needs to destroy the context on the thread where it was created. Even after fixing the ANGLE thread leak, there are still many leaks present. I am actively working to analyze these additional leaks.
loic-sharma commentedon Dec 2, 2023
@yaminet1024 Hm, on Windows we create the render and resource contexts on the platform thread at start up, before the engine is started and before the IO & raster threads exist. I wasn't aware of this ANGLE requirement though, where can I learn more about this topic? Perhaps our threading strategies is causing these leaks.
yaminet1024 commentedon Dec 12, 2023
Hi, Apologies for the delayed response. ,I found the problem just to debug angle code, I've pinpointed the issue to how eglMakeCurrent manages thread data. It appears that when eglMakeCurrent is called on the IO/Raster thread, the context gains a reference count, which is only decremented when eglMakeCurrent is invoked with EGL_NO_CONTEXT on the same thread. However, I couldn't find a call to makeCurrent(,,EGL_NO_CONTEXT) in the AngleManager.
Here are the relevant sections of the ANGLE codebase that I've been looking into:
Binding the context to a thread:
eglMakeCurrent Entry Point
eglMakeCurrent Stub
Display.cpp
I also discovered that eglDestroyContext will not fully clear all data If the context is still current on at least 1 thread.
eglDestroyContext
Furthermore, eglTerminate does not clear all the data either.
eglTerminate
It seems that flutter threading strategy might not be accounting for this reference count behavior, which could be leading to the leaks we're experiencing.
If I set EGL_NO_CONTEXT during the clear time on the raster/IO thread, I notice a 38MB reduction in memory usage when closing the Flutter window.
before:

after:

I'm curious as to why this approach wasn't implemented previously? Am I wrong to change it this way? If this change is indeed beneficial and doesn't introduce any issues, I would be glad to contribute a fix for this problem.
flutter-triage-bot commentedon Jun 6, 2024
The
triaged-desktoplabel is irrelevant if there is noteam-desktoplabel orfyi-desktoplabel.github-actions commentedon Aug 1, 2024
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.