org.eclipse.ui.tests.dialogs.UIEditWorkingSetWizardAuto.testEditPage fails on windows in the I-build intermittently
The test org.eclipse.ui.tests.dialogs.UIEditWorkingSetWizardAuto.testEditPage failed in the IBuild I20220817-1800 on Windows with the below error
Problems encountered while deleting resources.
junit.framework.AssertionFailedError: Problems encountered while deleting resources.
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:223)
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.deleteResources(UIWorkingSetWizardsAuto.java:102)
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.doTearDown(UIWorkingSetWizardsAuto.java:169)
at org.eclipse.ui.tests.harness.util.UITestCase.tearDown(UITestCase.java:214)
The test org.eclipse.ui.tests.dialogs.UIEditWorkingSetWizardAuto.testEditPage failed in the IBuild I20220824-1800 on Windows with the below error
Problems encountered while deleting resources.
junit.framework.AssertionFailedError: Problems encountered while deleting resources.
at junit.framework.Assert.fail(Assert.java:57)
at junit.framework.TestCase.fail(TestCase.java:223)
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.deleteResources(UIWorkingSetWizardsAuto.java:102)
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.doTearDown(UIWorkingSetWizardsAuto.java:169)
at org.eclipse.ui.tests.harness.util.UITestCase.tearDown(UITestCase.java:214)
It failed also during this PR-Build on May 2023.
#790 should help identify the problem
@HeikoKlare happended today again: https://download.eclipse.org/eclipse/downloads/drops4/I20230713-1800/testresults/html/org.eclipse.ui.tests_ep429I-unit-win32-java17_win32.win32.x86_64_17.html
java.lang.AssertionError: Problems encountered while deleting resources.
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.createAssertionError(UIWorkingSetWizardsAuto.java:115)
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.deleteResources(UIWorkingSetWizardsAuto.java:103)
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.doTearDown(UIWorkingSetWizardsAuto.java:199)
at org.eclipse.ui.tests.harness.util.UITestCase.tearDown(UITestCase.java:214)
I just noticed I hadn't properly tagged this issue in #560. fyi my PR aims to help identify the underlying error with a more meaningful stack trace.
A proper stack trace is already provided in the logs. For example, a recent failing IBuild shows:
!MESSAGE Could not delete 'C:\Users\genie.releng\workspace\AutomatedTests\ep429I-unit-win32-java17\workarea\I20230713-1800\eclipse-testing\test-eclipse\eclipse\ui_sniff_folder\TP2\.project'.
!STACK 1
org.eclipse.core.runtime.CoreException: Problems encountered while deleting files.
at org.eclipse.core.internal.filesystem.local.LocalFile.delete(LocalFile.java:163)
at org.eclipse.core.internal.resources.ResourceTree.internalDeleteFile(ResourceTree.java:316)
at org.eclipse.core.internal.resources.ResourceTree.internalDeleteProject(ResourceTree.java:437)
at org.eclipse.core.internal.resources.ResourceTree.standardDeleteProject(ResourceTree.java:856)
at org.eclipse.core.internal.resources.Resource.unprotectedDelete(Resource.java:1843)
at org.eclipse.core.internal.resources.Resource.delete(Resource.java:808)
at org.eclipse.core.internal.resources.Project.delete(Project.java:365)
at org.eclipse.ui.tests.harness.util.FileUtil.deleteProject(FileUtil.java:61)
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.deleteResources(UIWorkingSetWizardsAuto.java:98)
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.doTearDown(UIWorkingSetWizardsAuto.java:199)
at org.eclipse.ui.tests.harness.util.UITestCase.tearDown(UITestCase.java:214)
and
Contains: Could not delete: C:\Users\genie.releng\workspace\AutomatedTests\ep429I-unit-win32-java17\workarea\I20230713-1800\eclipse-testing\test-eclipse\eclipse\ui_sniff_folder\TP2\.project.
java.nio.file.FileSystemException: C:\Users\genie.releng\workspace\AutomatedTests\ep429I-unit-win32-java17\workarea\I20230713-1800\eclipse-testing\test-eclipse\eclipse\ui_sniff_folder\TP2\.project: The process cannot access the file because it is being used by another process
at java.base/sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:92)
at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:103)
at java.base/sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:108)
at java.base/sun.nio.fs.WindowsFileSystemProvider.implDelete(WindowsFileSystemProvider.java:275)
at java.base/sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:110)
at java.base/java.nio.file.Files.deleteIfExists(Files.java:1191)
at org.eclipse.core.internal.filesystem.local.LocalFile.internalDelete(LocalFile.java:244)
So for some reason the .project file is locked while the test tries to delete the project during cleanup.
You can provoke the error by manually locking the .project file by, e.g., executing FileChannel.open(pathToProjectFile, StandardOpenOption.APPEND).lock(); somewhere before resource deletion.
I could not figure out yet who concurrently accesses the file. I expect it to be some asynchronous task executed within the workspace (but thats rather a gut feeling than an analysis result).
Some slightly more analytic result: The logs show that the exception occurs during deletion of the second project. Since a project.delete triggers some actions (such as an auto build), I can image that the (asynchronously executed) effects of project.delete for the first project interfere with the deletion of the second project.
If that was really the case, it would point to some other issue, since there should, in my opinion, never be an access exception when trying to delete a project just because there is some asynchronous task running in the workspace.
I propose to simply put the two project deletions into a single workspace operation to avoid this potential kind of interference. That won't break anything and we can have a look at subsequent build results to figure out if that "solves" the issue. I have proposed an according PR in #941.
On windows it may just be that the filehandle was opened and not closed. You could debug where it is opened and verify if it's closed.
Yes, it could be the case that the file handle was not closed somewhere. Then this would (probably) be a symptom of some bug in the workspace code, as the test itself does not access the .project file.
In terms of debugging, I tried to do something similar, but during local execution I was not able to provoke any concurrent access to the file. I locked the file handle at the beginning of the test and waited for a significant amount of time before teardown to give workers (auto build, refresh etc.) the chance to perform their work, but the test only fails during teardown (when trying to delete the resource). So either no other asynchronous operations tried to lock the file in between or these other operations silently accept that the file is already locked.
Your proposal sound like "watching" the .project file handle after it has been created. Do you know some "easy" way to do that? From my understanding, this would require debugging at the Windows file system abstraction layer in Java. Since that may require quite some effort, I would defer that step and first see whether #941 gives some further insights.
Still occurs after #941: https://github.com/eclipse-platform/eclipse.platform.ui/actions/runs/5615102699/job/15214658654?pr=900
The test org.eclipse.ui.tests.dialogs.UIEditWorkingSetWizardAuto.testEditPage failed in the IBuild I20230927-1800 on Windows with the below error
Problems encountered while deleting resources.
java.lang.AssertionError: Problems encountered while deleting resources.
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.createAssertionError(UIWorkingSetWizardsAuto.java:156)
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.cleanupWorkspace(UIWorkingSetWizardsAuto.java:141)
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.doTearDown(UIWorkingSetWizardsAuto.java:123)
at org.eclipse.ui.tests.harness.util.UITestCase.tearDown(UITestCase.java:214)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
@HeikoKlare printing out the stacktrace when the test fails yields this:
(Error in English: "The process cannot access the file because it is being used by another process")
it looks like a file-lock is not yet reclaimed at the time we are trying to delete the file
I reproduced the error by running the test 100 times at once using this code (https://stackoverflow.com/questions/1492856/easy-way-of-running-the-same-junit-test-over-and-over):
/**
* Tests the WorkingSetEditWizard Tests input validation, presence of correct
* edit page and wizard page texts.
*/
@RunWith(Parameterized.class)
public class UIEditWorkingSetWizardAuto extends UIWorkingSetWizardsAuto<WorkingSetEditWizard> {
public UIEditWorkingSetWizardAuto() {
super(UIEditWorkingSetWizardAuto.class.getSimpleName());
}
@Parameterized.Parameters
public static Object[][] data() {
return new Object[100][0];
}
From my few experiments, I estimate it to occur roughly 3% of the runs
Failure still occurs after fix attempt in #1803. See for example this build: https://github.com/eclipse-platform/eclipse.platform.ui/pull/1823/checks?check_run_id=23971305789
Problems encountered while deleting resources.
java.lang.AssertionError: Problems encountered while deleting resources.
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.createAssertionError(UIWorkingSetWizardsAuto.java:156)
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.cleanupWorkspace(UIWorkingSetWizardsAuto.java:141)
at org.eclipse.ui.tests.dialogs.UIWorkingSetWizardsAuto.doTearDown(UIWorkingSetWizardsAuto.java:123)
at org.eclipse.ui.tests.dialogs.UIEditWorkingSetWizardAuto.doTearDown(UIEditWorkingSetWizardAuto.java:158)
at org.eclipse.ui.tests.harness.util.UITestCase.tearDown(UITestCase.java:214)