Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[desktop_multi_window] Handle leak (~3/cycle) when a sub-window is repeatedly destroyed and recreated

Aperta
  • Qualcosa non va?
#484 0 commenti 1 reazione 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Tranquilla
Stack tecnologico
dart
Ambito
desktop, operating-systems

Direzione di ricerca

Inizia da WindowController e dai gestori del canale desktop_multi_window per createWindow, quindi segui FlutterWindow::OnDestroy(), RemoveManagedFlutterWindowLater() e CleanupRemovedWindows(). Riproduci WM_CLOSE ripetuti e la ricreazione misurando GetProcessHandleCount; il lavoro è completato quando le sottofinestre distrutte vengono recuperate completamente senza una crescita lineare del numero di handle, con copertura del percorso di distruzione e ricreazione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

When a desktop_multi_window sub-window is destroyed (e.g. it receives WM_CLOSE, or dies for any reason) and then recreated, the host process leaks ~3 Windows handles per recreate cycle (linear). There is no public API to destroy a sub-window (only show()/hide()), and the engine resources are not fully reclaimed when the window closes.

Environment

  • Flutter 3.44.1 (stable), Windows 10 x64
  • desktop_multi_window: 0.3.0

Observed (measured)

Windows handle count via GetProcessHandleCount, across forced-destroy + auto-recreate cycles (PostMessage WM_CLOSE to the sub-window HWND, wait for the host app to recreate it):

cycles handles WorkingSet GDI USER
baseline 674 114.7 MB 25 39
after 15 720 (+46, ~3/cycle linear) 127.2 MB (+12.5) 25 (0) 40 (+1)
  • Recreation succeeds 15/15, process never crashes.
  • Normal operation (window kept alive, no recreation) shows no leak — handles stable (675 → 672) over 80s. So the leak is strictly tied to the destroy→recreate transition.

Analysis (from the 0.3.0 Windows source)

  • WindowController (Dart) exposes only show() / hide() — there is no close() / destroy().
  • The main channel mixin.one/desktop_multi_window handles only createWindow / getWindowDefinition / getAllWindows.
  • FlutterWindow::OnDestroy() sets flutter_controller_ = nullptr (destroying the FlutterViewController) and calls RemoveManagedFlutterWindowLater(id). The managed FlutterWindow is only erased later via CleanupRemovedWindows(), which is invoked solely on the next Create().
  • Even with that cleanup running, ~3 handles/cycle are not reclaimed — suggesting FlutterViewController/engine teardown on Windows does not fully release its thread/event handles.

Reproduction

  1. WindowController.create(...) a sub-window.
  2. Force-close it: PostMessage(hwnd, WM_CLOSE, 0, 0) to the sub-window's top-level HWND.
  3. Recreate via WindowController.create(...).
  4. Repeat. Watch GetProcessHandleCount(process) climb ~3 per cycle.

Impact

  • Typical apps: negligible — sub-windows rarely die, so they're rarely recreated.
  • Apps that auto-recreate a sub-window for resilience (e.g. an always-on-top overlay that respawns if it disappears) can accumulate handles over time if the window dies repeatedly.

Suggestions

  1. Add an explicit WindowController.close() (Dart) + closeWindow native handler that destroys the sub-window and immediately tears down its FlutterViewController and erases it from managed_flutter_windows_, instead of deferring to the next Create().
  2. Investigate whether FlutterViewController teardown itself leaks handles on Windows — if so, an upstream flutter/flutter follow-up may be warranted.

Happy to provide the full measurement harness (Win32 EnumWindows/GetProcessHandleCount/GetGuiResources) if useful.

Lingua principale
C
Stelle
512
Fork
296
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di MixinNetwork/flutter-plugins

Tutte le issue di MixinNetwork/flutter-plugins

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.