File handle to findsecbugs-plugin.jar is leaking

[Vampire]

A file handle to findsecbugs-plugin.jar is leaking.
When I run a SonarQube analysis with Gradle Scanner with activated Gradle Daemon on Windows and after the analysis is finished try to delete the build/sonar/ folder, Windows is yelling at me that the findsecbugs-plugin.jar files for each project are in use.
This means that the Findbugs plugin or Findbugs is leaking the reference to that JAR.
It would be nice if this would not be the case.

[svilenvul]

I have experienced similar problems with the spotbugs-maven-plugins.

[h3xstream]

There is a fix in progress : spotbugs/spotbugs#591

[Vampire]

Is this fixed?
The issue you referenced is marked with merged and milestone 3.1.4.

[AndreasPetersen]

I'm still having the issue with sonar-findbugs 3.11.0

[h3xstream]

I did not do any advanced analysis..

Here is the code loading the plugin. I don't see any state kept in this class which could keep a reference to the file of the plugin.

sonar-findbugs/src/main/java/org/sonar/plugins/findbugs/FindbugsExecutor.java

Lines 271 to 278 in b7ca5dd

	for (String path : pluginJarPathList) {
	try {
	Plugin plugin = Plugin.addCustomPlugin(new File(path).toURI(), contextClassLoader);
	if (plugin != null) {
	customPluginList.add(plugin);
	LOG.info("Loading findbugs plugin: " + path);
	}
	} catch (PluginException e) {

Could it be SpotBugs which is keeping some sort of cache or having a circular reference? Or is specifically FSB ?

Heap analysis with VisualVM will likely help track this reference..

[KengoTODA]

I know one case, is that, Windows uses cache and it keep file handle opened by JVM. Then URLConnection#setUseCaches(false) is necessary to avoid this handler leak.

In my understanding, SpotBugs has fixed this issue by the following commit, but we may miss other problem that still keeps handler in Windows.

spotbugs/spotbugs@5f88794#diff-dad40536bc9bd97552925b9c1566a005R286

[KengoTODA]

I guess that we probably need a fix like this? Is there anybody can reproduce this issue?

diff --git a/spotbugs/src/main/java/edu/umd/cs/findbugs/PluginLoader.java b/spotbugs/src/main/java/edu/umd/cs/findbugs/PluginLoader.java
index f4112bb72..fbfe3c352 100644
--- a/spotbugs/src/main/java/edu/umd/cs/findbugs/PluginLoader.java
+++ b/spotbugs/src/main/java/edu/umd/cs/findbugs/PluginLoader.java
@@ -222,6 +222,9 @@ public class PluginLoader {
             }
             partiallyInitialized.add(this);
         } else {
+            if (classLoader instanceof URLClassLoader) {
+                ((URLClassLoader) classLoader).setUseCaches(false);
+            }
             loadPluginComponents();
             Plugin.putPlugin(loadedFromUri, plugin);
         }

[ecast040]

I'm having this exact issue with the sonarqube plugin, Is there a fix for this yet? Where do I go to add the .setUseCaches(false) ?

[nubang7]

I`m having same issue still today. Can not build Gradle project cause findsecbugs-plugin.jar is locked after SonarQube task ran.

[KengoTODA]

If you can reproduce this problem, try this patch and share the result if possible.

[paulthvt]

I'm still having the same issue. I was interested to try this patch out but it won't compile. There's no setUseCaches method on URLClassLoader unfortunately.

[Daemon2017]

I'm still having the same issue :(
Plugin version: 3.0

[yuriy-slobodchikov]

Reproduced

Plugin version: 3.1.1

[aantenan]

If you run gradle with --no-daemon, it kills all JVM processes upon completion. This may work for a few use cases.

[gtoison]

I ran into that issue while working into another problem with Gradle and could reproduce it all the time.
It seems to me like the issue might actually be due to some sockets held by the SonarQube scanner and preventing the Garbage Collector from releasing these files.
There also seem to be some temporary folders accumulating, for me they land in:
C:\Users\gtoison\.sonar\cache\<some random string>\sonar-findbugs-plugin.jar_unzip\META-INF\lib
Anyone knows if it also happens for other plugins?

It would be great if anyone knowledgeable of the JVM internals could look into, maybe I completely misunderstood the problem.
I have posted a question on SonarQube's forum here: https://community.sonarsource.com/t/file-leak-with-gradle-plugin/57438/4