Closed haubi closed 2 years ago
looks like the com.wamas.ide.launching.ui.build.LcDslTargetPlatformSupport.uriMap is completed too late - @szarnekow could you please take a look into the stacktrace.
here the code relys on uriMap already initialized while it is currently in the initializeCache():
at com.google.common.util.concurrent.Futures.getUnchecked(Futures.java:1317)
at com.wamas.ide.launching.ui.build.LcDslTargetPlatformSupport.stateChanged(LcDslTargetPlatformSupport.java:554) <--use cache
at org.eclipse.pde.internal.core.PluginModelManager.fireStateChanged(PluginModelManager.java:427)
at org.eclipse.pde.internal.core.PluginModelManager.initializeTable(PluginModelManager.java:644)
- locked <0x0000000704146b58> (a org.eclipse.pde.internal.core.PluginModelManager)
at org.eclipse.pde.internal.core.PluginModelManager.getExternalModels(PluginModelManager.java:1178)
at com.wamas.ide.launching.ui.build.LcDslTargetPlatformSupport.lambda$11(LcDslTargetPlatformSupport.java:201) <--initializeCache()
I'm not at my machine right now but judging from the stack and from what I remember: It looks like we can skip all handling of events if the future is not done yet. The event processing should only be necessary to update the cached information. The update is not necessary if nothing was cached yet.
When updating our internal IDE (based on Eclipse 2022-03) to ship with eaa541d8e94ce5b678e605be7d8557ac02db5a1a, our internal CI builds (using TEA tasks) hang somewhere around "loading target platform" when about to set up the workspace for building the IDE.
Some stack dump is available in ldcsl-202205201343-hang-stackdump.txt
This is a regression since 413d2aa67bd16757c4ebc55113ded1b6a2ce62cb.
Before I start trying to reproduce in a local workspace: @szarnekow @jukzi Any idea so far?