org.eclipse.ui.tests.dialogs.UIEditWorkingSetWizardAuto.testEditPage fails on windows in the I-build intermittently #275
Comments
|
The test org.eclipse.ui.tests.dialogs.UIEditWorkingSetWizardAuto.testEditPage failed in the IBuild I20220824-1800 on Windows with the below error |
|
It failed also during this PR-Build on May 2023. |
…ipse-platform#275 Find the most severe status in the caught exception and use its stack trace in order to be able to see where the error originated.
…ipse-platform#275 Find the most severe status in the caught exception and use its stack trace in order to be able to see where the error originated.
…ipse-platform#275 Find the most severe status in the caught exception and use its stack trace in order to be able to see where the error originated.
|
#790 should help identify the problem |
…ipse-platform#275 Find the most severe status in the caught exception and use its stack trace in order to be able to see where the error originated.
…ipse-platform#275 Find the most severe status in the caught exception and use its stack trace in order to be able to see where the error originated.
Find the most severe status in the caught exception and use its stack trace in order to be able to see where the error originated.
|
@HeikoKlare happended today again: |
|
I just noticed I hadn't properly tagged this issue in #560. |
|
A proper stack trace is already provided in the logs. For example, a recent failing IBuild shows: and So for some reason the |
The UIEditWorkingSetWizardAuto#testEditPage randomly fails because the project deletion during test cleanup fails. The project file of the second project to be deleted is already locked. To avoid that the deletion of the first project triggers some asynchronous tasks that interfere with the deletion of the second project, this change combines both deletions into an atomic workspace operation. In addition, the change separates the exception handling for both projects to see from the stack trace which of the deletions caused the exception. Contributes to eclipse-platform#275
|
You can provoke the error by manually locking the 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). 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 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 |
The UIEditWorkingSetWizardAuto#testEditPage randomly fails because the project deletion during test cleanup fails. The project file of the second project to be deleted is already locked. To avoid that the deletion of the first project triggers some asynchronous tasks that interfere with the deletion of the second project, this change combines both deletions into an atomic workspace operation. In addition, the change separates the exception handling for both projects to see from the stack trace which of the deletions caused the exception. Contributes to #275
…m#275 The tests for working set wizards change the workspace's working sets without resetting them afterwards. Instead, they cleanup working sets during test setup. In addition, workspace resources are cleaned up selectively after test execution instead of cleaning up the workspace resources into total. This change addresses this a follows: - Cleans up working set changes after test execution - Improves resource cleanup by deleting all workspace resources - Refactors test implementations by improving encapsulation in test classes to avoid unwanted/undetected side effects that may be related to random failures of UIEditWorkingSetWizardAuto.testEditPage
The UIEditWorkingSetWizardAuto#testEditPage randomly fails because the project deletion during test cleanup fails. The project file of the second project to be deleted is already locked. To avoid that the deletion of the first project triggers some asynchronous tasks that interfere with the deletion of the second project, this change combines both deletions into an atomic workspace operation. In addition, the change separates the exception handling for both projects to see from the stack trace which of the deletions caused the exception. Contributes to eclipse-platform#275
…m#275 The tests for working set wizards change the workspace's working sets without resetting them afterwards. Instead, they cleanup working sets during test setup. In addition, workspace resources are cleaned up selectively after test execution instead of cleaning up the workspace resources into total. This change addresses this a follows: - Cleans up working set changes after test execution - Improves resource cleanup by deleting all workspace resources - Refactors test implementations by improving encapsulation in test classes to avoid unwanted/undetected side effects that may be related to random failures of UIEditWorkingSetWizardAuto.testEditPage Contributes to eclipse-platform#275
|
The test org.eclipse.ui.tests.dialogs.UIEditWorkingSetWizardAuto.testEditPage failed in the IBuild I20230927-1800 on Windows with the below error |
|
@HeikoKlare printing out the stacktrace when the test fails yields this: 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 |
…atform#275 In my experiments, the test failed in roughly 2% of runs. The test didn't close all processes and editors before deleting the files it contained. This PR Makes the Job-Manager join all jobs before finally deleting the project-root. eclipse-platform#275
…atform#275 In my experiments, the test failed in roughly 2% of runs. The test didn't close all processes which potentially accessed the files it contained. This PR Makes the Job-Manager join all jobs before finally deleting the project-root. eclipse-platform#275
…atform#275 In my experiments, the test failed in roughly 2% of runs. The test didn't close all processes which potentially accessed the files it contained. This PR Makes the Job-Manager join all jobs before finally deleting the project-root. eclipse-platform#275
…atform#275 In my experiments, the test failed in roughly 2% of runs. The test didn't close all processes which potentially accessed the files it contained. This PR Makes the Job-Manager join all jobs before finally deleting the project-root. eclipse-platform#275
…atform#275 In my experiments, the test failed in roughly 2% of runs. The test didn't close all processes which potentially accessed the files it contained. This PR Makes the Job-Manager join all jobs before finally deleting the project-root. eclipse-platform#275
…atform#275 In my experiments, the test failed in roughly 2% of runs. The test didn't close all processes which potentially accessed the files it contained. This PR Makes the Job-Manager join all jobs before finally deleting the project-root. eclipse-platform#275
…atform#275 In my experiments, the test failed in roughly 2% of runs. The test didn't close all processes which potentially accessed the files it contained. This PR Makes the Job-Manager join all jobs before finally deleting the project-root. eclipse-platform#275
In my experiments, the test failed in roughly 2% of runs. The test didn't close all processes which potentially accessed the files it contained. This PR Makes the Job-Manager join all jobs before finally deleting the project-root. #275
|
Failure still occurs after fix attempt in #1803. |
The test org.eclipse.ui.tests.dialogs.UIEditWorkingSetWizardAuto.testEditPage failed in the IBuild I20220817-1800 on Windows with the below error
The text was updated successfully, but these errors were encountered: