FlutterAppManager is never disposed

[intellitour]

What happened

I was not even using the plugin by the time this popped up. I have no idea why or how.

Version information

IntelliJ IDEA 2022.3 • Flutter plugin io.flutter 71.0.6 • Dart plugin 223.7571.203

Flutter 3.3.9 • channel stable • https://github.com/flutter/flutter.git
Framework • revision b8f7f1f986 (3 weeks ago) • 2022-11-23 06:43:51 +0900
Engine • revision 8f2221fbef
Tools • Dart 2.18.5 • DevTools 2.15.0

Exception

null

com.intellij.serviceContainer.AlreadyDisposedException: Cannot create com.intellij.execution.ui.RunContentManager because container is already disposed (container=ClientId(value=Host))
	at com.intellij.serviceContainer.ContainerUtilKt.throwAlreadyDisposedError(containerUtil.kt:40)
	at com.intellij.serviceContainer.ComponentManagerImpl.getComponent(ComponentManagerImpl.kt:605)
	at com.intellij.serviceContainer.ComponentManagerImpl.doGetService(ComponentManagerImpl.kt:717)
	at com.intellij.openapi.client.ClientSessionImpl.doGetService(ClientSessionImpl.kt:97)
	at com.intellij.openapi.client.ClientAwareComponentManager.postGetService(ClientAwareComponentManager.kt:39)
	at com.intellij.serviceContainer.ComponentManagerImpl.getServiceIfCreated(ComponentManagerImpl.kt:664)
	at com.intellij.openapi.components.ServiceManager.getServiceIfCreated(ServiceManager.java:36)
	at io.flutter.run.FlutterAppManager.getRunContentManager(FlutterAppManager.java:124)
	at io.flutter.run.FlutterAppManager.getActiveApp(FlutterAppManager.java:65)
	at io.flutter.run.FlutterAppManager.updateActiveApp(FlutterAppManager.java:112)
	at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539)
	at java.base/java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305)
	at com.intellij.util.concurrency.SchedulingWrapper$MyScheduledFutureTask.run(SchedulingWrapper.java:275)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:702)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1$1.run(Executors.java:699)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
	at java.base/java.util.concurrent.Executors$PrivilegedThreadFactory$1.run(Executors.java:699)
	at java.base/java.lang.Thread.run(Thread.java:833)

[stevemessick]

FlutterAppManager does Disposer.register(project, this); which is incorrect because projects are not disposed. It needs an alternative dispose mechanism.

[alexander-doroshko]

Projects are being disposed when being closed, together with the whole tree of dependent disposables.

I think the cause of this exception is that the updateActiveApp() call was scheduled at the moment when the project was not yet disposed but executed later, when the project was already disposed.

The easiest fix would be to return null from the getRunContentManager() method if the project is disposed.

[stevemessick]

Thanks, Alex, that sounds like the easiest fix. My comment was based on the big red block of text on this page, that says to not use projects as disposable parents: https://plugins.jetbrains.com/docs/intellij/disposers.html#choosing-a-disposable-parent

Edit: And I mis-remembered the reason for not using them as parents. Of course they get disposed when closed, duh.

[alexander-doroshko]

True, Application and Project as parent disposables will cause memory leaks for dynamic plugins, i.e. the plugins that can be loaded/unloaded on-the-fly without an IDE restart.

Flutter plugin in its current state is not dynamic, so using Application and Project as parent disposables is not dangerous.

Still, if you use AnyFlutterPluginProjectService.getInstance(project) as parent disposable it will work the same as project and will be dynamic plugins concept-friendly. Best practices is to use AnyFlutterPluginProjectService which is already in hands at the point of using (quite often the best service is just this). If none in hands then use the one which is definitely already loaded at this point - in order not to instantiate the service with the only purpose of using it as parent disposable.