[
https://issues.apache.org/jira/browse/GROOVY-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16342069#comment-16342069
]
Peter Kriens commented on GROOVY-8458:
--------------------------------------
Ok, looking at the code and your comment I understand the loaders stay open,
which is explaining the problem. Setting an option in eclipse.ini is of course
very awkward.
I see the following solutions:
1) bnd does a GC before we access these files (or after we get the exception).
The URLClassLoader keeps the files 'weakly' open. This of course is ugly in our
code and it costs time. (Though in a large build this is likely amortized since
one GC would work for all.)
2) bnd sets greclipse.nonlocking=true. Although we then need to make sure we
are executed before Groovy which might be hard, if at all possible.
3) Groovy adapts to use the NonLockingJarFileClassLoader by default, or
provides a preference for this
Clearly my rather strong preference is #3 since that follows the Eclipse rules,
I expect there are non bnd use cases that also get this error. bnd is just very
prone to this problem because we change the Eclipse build path all the time.
Would that be possible?
> File leak in Eclipse Plugin
> ---------------------------
>
> Key: GROOVY-8458
> URL: https://issues.apache.org/jira/browse/GROOVY-8458
> Project: Groovy
> Issue Type: Bug
> Reporter: Peter Kriens
> Priority: Blocker
>
> The Eclipse Groovy compiler opens JAR files that are on an Eclipse's project
> build path. These JAR files are opened by Groovy but never closed.
> When a project changes its buildpath, the Groovy compiler keeps a reference
> to the old file which makes it impossible to overwrite it on Windows.
> This is very visible in bnd(tools) environments because bnd creates an actual
> bundle and puts this on the project's build path. Since every change results
> in a new bundle, the build path is changed very frequently. However, once the
> Groovy compiler has its hands on that JAR, bnd can no longer delete and its
> build fails.
> When we run an Eclipse workspace with a number of bnd projects we see a large
> number of the following file leaks at the end.
> Looking at the source code it seems that you're opening a GroovyClassLoader,
> to get some resources to find the AST transform services from it, and then
> never close it. So the JAR files it accesses are then never closed. Which
> kind of is a problem on Windows ..
> [https://github.com/groovy/groovy-core/blob/01309f9d4be34ddf93c4a9943b5a97843bff6181/src/main/org/codehaus/groovy/transform/ASTTransformationVisitor.java#L197]
> It seems putting this in a try/resource will solve the problem.
> Although we did not detect leaks from different places, in our experience,
> these patterns tend to happen frequently in a code base so it would be
> appreciated to do a check on any classloaders (which are Java resources so
> you can get a warning from Eclipse when you forget to close a Closeable
> resource) are not closed.
>
> Let me know if you prefer a pull request on Github.
>
>
> #95 C:\Users\-\com._______________\target\com._______________.jar by
> thread:Worker-11 on Wed Jan 24 10:30:25 CET 2018 at
> java.util.zip.ZipFile.<init>(ZipFile.java:156) at
> java.util.jar.JarFile.<init>(JarFile.java:166) at
> java.util.jar.JarFile.<init>(JarFile.java:103) at
> sun.misc.URLClassPath$JarLoader.getJarFile(URLClassPath.java:930) at
> sun.misc.URLClassPath$JarLoader.access$800(URLClassPath.java:791) at
> sun.misc.URLClassPath$JarLoader$1.run(URLClassPath.java:876) at
> sun.misc.URLClassPath$JarLoader$1.run(URLClassPath.java:869) at
> java.security.AccessController.doPrivileged(Native Method) at
> sun.misc.URLClassPath$JarLoader.ensureOpen(URLClassPath.java:868) at
> sun.misc.URLClassPath$JarLoader.<init>(URLClassPath.java:841) at
> sun.misc.URLClassPath$3.run(URLClassPath.java:565) at
> sun.misc.URLClassPath$3.run(URLClassPath.java:555) at
> java.security.AccessController.doPrivileged(Native Method) at
> sun.misc.URLClassPath.getLoader(URLClassPath.java:554) at
> sun.misc.URLClassPath.getLoader(URLClassPath.java:519) at
> sun.misc.URLClassPath.getNextLoader(URLClassPath.java:484) at
> sun.misc.URLClassPath.access$100(URLClassPath.java:65) at
> sun.misc.URLClassPath$1.next(URLClassPath.java:266) at
> sun.misc.URLClassPath$1.hasMoreElements(URLClassPath.java:277) at
> java.net.URLClassLoader$3$1.run(URLClassLoader.java:601) at
> java.net.URLClassLoader$3$1.run(URLClassLoader.java:599) at
> java.security.AccessController.doPrivileged(Native Method) at
> java.net.URLClassLoader$3.next(URLClassLoader.java:598) at
> java.net.URLClassLoader$3.hasMoreElements(URLClassLoader.java:623) at
> sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) at
> sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) at
> sun.misc.CompoundEnumeration.next(CompoundEnumeration.java:45) at
> sun.misc.CompoundEnumeration.hasMoreElements(CompoundEnumeration.java:54) at
> org.codehaus.groovy.transform.ASTTransformationVisitor.doAddGlobalTransforms(ASTTransformationVisitor.java:240)
> at
> org.codehaus.groovy.transform.ASTTransformationVisitor.addGlobalTransforms(ASTTransformationVisitor.java:228)
> at
> org.codehaus.groovy.transform.ASTTransformationVisitor.addPhaseOperations(ASTTransformationVisitor.java:191)
> at
> org.codehaus.groovy.control.CompilationUnit.<init>(CompilationUnit.java:222)
> at
> org.codehaus.jdt.groovy.internal.compiler.ast.GroovyParser.makeCompilationUnit(GroovyParser.java:467)
> at
> org.codehaus.jdt.groovy.internal.compiler.ast.GroovyParser.<init>(GroovyParser.java:245)
> at
> org.codehaus.jdt.groovy.integration.internal.MultiplexingParser.dietParse(MultiplexingParser.java:49)
> at
> org.eclipse.jdt.internal.compiler.Compiler.internalBeginToCompile(Compiler.java:845)
> at
> org.eclipse.jdt.internal.compiler.Compiler.beginToCompile(Compiler.java:397)
> at org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:447) at
> org.eclipse.jdt.internal.compiler.Compiler.compile(Compiler.java:429) at
> org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:396)
> at
> org.eclipse.jdt.internal.core.builder.BatchImageBuilder.compile(BatchImageBuilder.java:191)
> at
> org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:329)
> at
> org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:62)
> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:256)
> at
> org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:175)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:735)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at
> org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:301) at
> org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at
> org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:304)
> at
> org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:360)
> at
> org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:383) at
> org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:142)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:232)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:56)
>
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
