[jira] [Comment Edited] (GROOVY-8458) File leak in Eclipse Plugin

["Jochen Theodorou (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/GROOVY-8458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16341103#comment-16341103 ] 

Jochen Theodorou edited comment on GROOVY-8458 at 1/26/18 2:24 PM:
-------------------------------------------------------------------

The question is when exactly is it valid to call close on a URLClassLaoder. Here you point the transform loader. This loader basically given to the compiler from "outside". This means only outside the compiler, or at a defined entry/exit point can we close the transform loader. I am missing this point in case of GroovyClassLoader. This needs to be a level higher. It needs to be at the place where CompleUnit is controlled. And here this sounds to me like the eclipse plugin. You are welcome to discuss the right place here with me.


was (Author: blackdrag):
The question is when exactly is it valid to call close on a URLClassLaoder. Here you point the transform loader. This loader basically given to the compiler from "outside". This means only outside the compiler, or at a defined entry/exit point can we close the transform loader. I am missing this point in case of GroovyClassLoader. This needs to be a level higher. It needs to be at the place where CompleUnit is controlled. And here this sounds to me like the eclipse plugin

> 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)