Random Stream closed in multiproject build, Detekt 1.19.0, JDK 1.8

[davidburstrom]

Ran on JDK 1.8, analysing multiple modules in parallel. Probably the standard issue with reusing cached zip streams within the same VM.

Caused by: java.io.IOException: Stream closed
at io.gitlab.arturbosch.detekt.core.config.ValidateConfigKt.validateConfig$getDeprecatedProperties(ValidateConfig.kt:71)$
at io.gitlab.arturbosch.detekt.core.config.ValidateConfigKt.validateConfig$testKeys(ValidateConfig.kt:83)$
at io.gitlab.arturbosch.detekt.core.config.ValidateConfigKt.validateConfig$testKeys(ValidateConfig.kt:107)$
at io.gitlab.arturbosch.detekt.core.config.ValidateConfigKt.validateConfig$testKeys(ValidateConfig.kt:107)$
at io.gitlab.arturbosch.detekt.core.config.ValidateConfigKt.validateConfig(ValidateConfig.kt:113)$
at io.gitlab.arturbosch.detekt.core.config.ValidateConfigKt.validateConfig(ValidateConfig.kt:34)$
at io.gitlab.arturbosch.detekt.core.config.CompositeConfig.validate(CompositeConfig.kt:31)$
at io.gitlab.arturbosch.detekt.core.config.ValidateConfigKt.validateConfig(ValidateConfig.kt:114)$
at io.gitlab.arturbosch.detekt.core.config.ValidateConfigKt.validateConfig(ValidateConfig.kt:34)$
at io.gitlab.arturbosch.detekt.core.config.DefaultPropertiesConfigValidator.validate(DefaultPropertiesConfigValidator.kt:24)$
at io.gitlab.arturbosch.detekt.core.config.ConfigValidatorsKt.checkConfiguration(ConfigValidators.kt:18)$
at io.gitlab.arturbosch.detekt.core.tooling.Lifecycle$analyze$1.invoke(Lifecycle.kt:35)$
at io.gitlab.arturbosch.detekt.core.tooling.Lifecycle$analyze$1.invoke(Lifecycle.kt:35)$
at io.gitlab.arturbosch.detekt.core.util.PerformanceMonitor.measure(PerformanceMonitor.kt:42)$
at io.gitlab.arturbosch.detekt.core.tooling.Lifecycle$DefaultImpls.measure(Lifecycle.kt:32)$
at io.gitlab.arturbosch.detekt.core.tooling.Lifecycle$DefaultImpls.analyze(Lifecycle.kt:35)$
at io.gitlab.arturbosch.detekt.core.tooling.DefaultLifecycle.analyze(Lifecycle.kt:59)$
at io.gitlab.arturbosch.detekt.core.tooling.AnalysisFacade$runAnalysis$1.invoke(AnalysisFacade.kt:43)$
at io.gitlab.arturbosch.detekt.core.tooling.AnalysisFacade$runAnalysis$1.invoke(AnalysisFacade.kt:42)$
at io.gitlab.arturbosch.detekt.core.tooling.ProcessingSpecSettingsBridgeKt.withSettings(ProcessingSpecSettingsBridge.kt:26)$
at io.gitlab.arturbosch.detekt.core.tooling.AnalysisFacade.runAnalysis$detekt_core(AnalysisFacade.kt:42)$
at io.gitlab.arturbosch.detekt.core.tooling.AnalysisFacade.run(AnalysisFacade.kt:25)$
at io.gitlab.arturbosch.detekt.cli.runners.Runner.call(Runner.kt:33)$
at io.gitlab.arturbosch.detekt.cli.runners.Runner.execute(Runner.kt:23)$
at io.gitlab.arturbosch.detekt.invoke.DefaultCliInvoker.invokeCli(DetektInvoker.kt:59)$
at io.gitlab.arturbosch.detekt.Detekt.check(Detekt.kt:252)$
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)$

Your Environment

• JDK 1.8
• Version of Detekt used: 1.19.0
• Version of Gradle used (if applicable): 7.3.1
• Operating System and version: macOS Monterey

[cortinico]

Ran on JDK 1.8, analysing multiple modules in parallel

Which type of parallelism are you using? Gradle parallel execution or Detekt --parallel?
Also is this happening only on JDK 8 or also on other JDKs?

[davidburstrom]

My special parallel execution :) Detekt loaded and executed by isolated class loaders in parallel.

[cortinico]

My special parallel execution :) Detekt loaded and executed by isolated class loaders in parallel.

Gotcha. I'm unsure what we can do to address this bug then. Any idea?

[davidburstrom]

I'll sound like a broken record, but it's the same solution as always: instead of calling getResourceAsStream(), call getResource() and open the URL connection with caches turned off.

[BraisGabin]

Then I think that this issue is fixed in 1.20.0 by #4334. Could you try the last SNAPSHOT? We shouldn't have any call to getResourceAsStream now.

[davidburstrom]

That looks really promising indeed!

[davidburstrom]

Ah, still breaks:

detekt/detekt-core/src/main/kotlin/io/gitlab/arturbosch/detekt/core/config/ValidateConfig.kt

Line 70 in 5fa01a9

return settings.javaClass.classLoader.getResourceAsStream("deprecation.properties")!!.use { inputStream ->

You also need to look for ClassLoader.getResourceAsStream()

[BraisGabin]

Added that function too as forbidden and use the safe one.

[davidburstrom]

As far as I can tell, the latest snapshot fixed the problem. Thanks!

[BraisGabin]

Thank you to keep pushing to fix this. It take a while but let's hope that it'd fixed for good now.