Community
Participate
Working Groups
Andrey Loskutov reported in bug 571614#c15 > Jörg, there are few new regressions in JDT UI tests: > > https://download.eclipse.org/eclipse/downloads/drops4/I20210815-0600/ > testresults/html/org.eclipse.jdt.ui.tests_ep421I-unit-win32-java11_win32. > win32.x86_64_11.html All the failing test are from ContentProviderTests3. All Errors are either "Could not delete 'C:\jenkins_agent\workspace\ep419I-unit-win32-java11-new\workarea\I20210815-0600\eclipse-testing\test-eclipse\eclipse\jdt_folder\TestProject1\mylib.jar'." or "Resource '/TestProject1/mylib.jar' already exists". The later seem to be a follow up error from the first error. => the root error during delete was "The process cannot access the file because it is being used by another process." (This sounds similar to bug 573363) Something has still a file handle open to that jar. I retried the test several times. When i put a breakpoint at LocalFile.internalDelete() i was sometimes able to reprduce the error. Some timing issue? I took a heapdump at that state and analysed it in the OQL Console: select {instance: s, content: s.toString()} from java.lang.String s where s.toString().contains("mylib") There where 2 GC roots for the filehandle: -- path in java.io.RandomAccessFile#68 : C:\Users\JKubitz\eclipseDev\jdt\junit-workspace\TestProject1\mylib.jar zfile in java.util.zip.ZipFile$Source#65 zsrc in java.util.zip.ZipFile$CleanableResource#64 action in jdk.internal.ref.CleanerImpl$PhantomCleanableRef#101 discovered in jdk.internal.ref.CleanerImpl$PhantomCleanableRef#60 next in jdk.internal.ref.CleanerImpl$PhantomCleanableRef#61 [GC root - JNI global] -- path in sun.nio.fs.WindowsPath#335 filePath in java.io.File#362 : C:\Users\JKubitz\eclipseDev\jdt\junit-workspace\TestProject1\mylib.jar file in java.util.zip.ZipFile$Source$Key#65 key in java.util.HashMap$Node#82287 [150] in java.util.HashMap$Node[]#6587 : 256 items table in java.util.HashMap#4951 static files in class java.util.zip.ZipFile$Source [GC root - sticky class] : ZipFile$Source -- Both GC roots point to a ZipFile. I further put a conditional breakpoint at ZipFile. And there where only 3 stacktraces that opend that file: Thread [main] (Suspended (breakpoint at line 228 in ZipFile)) owns: RunnableLock (id=2053) JavaModelManager.getZipFile(IPath, boolean) line: 2896 JavaModelManager.getZipFile(IPath) line: 2865 JavaModelManager.verifyArchiveContent(IPath) line: 2846 ClasspathEntry.validateLibraryContents(IPath, IJavaProject, String) line: 2514 ClasspathEntry.validateLibraryEntry(IPath, IJavaProject, String, IPath, String, boolean) line: 2440 ClasspathEntry.validateClasspathEntry(IJavaProject, IClasspathEntry, IClasspathContainer, boolean, boolean) line: 2303 ClasspathEntry.validateClasspathEntry(IJavaProject, IClasspathEntry, boolean, boolean) line: 2174 ClasspathValidation.validate() line: 75 SetClasspathOperation(ChangeClasspathOperation).classpathChanged(ClasspathChange, boolean) line: 55 ... Thread [main] (Suspended (breakpoint at line 228 in ZipFile)) owns: RunnableLock (id=2053) JavaModelManager.getZipFile(IPath, boolean) line: 2896 JavaModelManager.getZipFile(IPath) line: 2865 ClasspathEntry.getManifestContents(IPath) line: 1016 ClasspathEntry.getCalledFileNames(IPath) line: 1043 ClasspathEntry.resolvedChainedLibraries(IPath, HashSet, ArrayList) line: 983 ClasspathEntry.resolvedChainedLibraries(IPath) line: 970 ClasspathEntry.resolvedChainedLibraries() line: 1673 JavaProject.resolveClasspath(IClasspathEntry[], IClasspathEntry[], boolean, boolean) line: 3303 JavaProject.resolveClasspath(JavaModelManager$PerProjectInfo, boolean, boolean) line: 3414 JavaProject.getResolvedClasspath() line: 2498 ExternalFolderChange.updateExternalFoldersIfNecessary(boolean, IProgressMonitor) line: 42 SetClasspathOperation(ChangeClasspathOperation).classpathChanged(ClasspathChange, boolean) line: 63 SetClasspathOperation.executeOperation() line: 78 SetClasspathOperation(JavaModelOperation).run(IProgressMonitor) line: 740 ... Daemon Thread [Java indexing] (Suspended (breakpoint at line 228 in ZipFile)) ZipFile.<init>(File, int, Charset) line: 228 ZipFile.<init>(File, int) line: 177 ZipFile.<init>(File) line: 191 AddJarFileToIndex.execute(IProgressMonitor) line: 150 IndexManager(JobManager).run() line: 432 Thread.run() line: 834 => 2 Stacktraces in "main" thread. And 1 "Java indexing". Either the main threads somhow leaks ZipFile or "Java indexing" leaks it or still holds it.
New Gerrit change created: https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/184069
There was also a call to getArchiveValidity which leaked getZipFile if the test ran for more then 120seconds.
(In reply to Jörg Kubitz from comment #2) > There was also a call to getArchiveValidity which leaked getZipFile if the > test ran for more then 120seconds. This is actually a regression in 4.21, via bug 571340, caused by the old code from bug 455042 not properly working for *bad* jars now to leak also "valid" jars.
Gerrit change https://git.eclipse.org/r/c/jdt/eclipse.jdt.core/+/184069 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=0de2c95e6889aebeb2d743e2a71e6cefde96261e
Thanks Jörg.
Verified with Eclipse 4.21 M3 Version: 2021-09 (4.21) Build id: I20210818-1800 [by code check]
