Repository navigation
AliasManager not thread-safe (causes random failing org.eclipse.core.tests.internal.alias.BasicAliasTest.testBug256837 ) #95
Description
java.lang.NullPointerException
at org.eclipse.core.tests.internal.alias.BasicAliasTest.testBug256837(BasicAliasTest.java:457)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at junit.framework.TestCase.runTest(TestCase.java:177)
at junit.framework.TestCase.runBare(TestCase.java:142)
at junit.framework.TestResult$1.protect(TestResult.java:122)
at junit.framework.TestResult.runProtected(TestResult.java:142)
at junit.framework.TestResult.run(TestResult.java:125)
at junit.framework.TestCase.run(TestCase.java:130)
at junit.framework.TestSuite.runTest(TestSuite.java:241)
at junit.framework.TestSuite.run(TestSuite.java:236)
at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:90)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runners.Suite.runChild(Suite.java:128)
at org.junit.runners.Suite.runChild(Suite.java:27)
at org.junit.runners.ParentRunner$4.run(ParentRunner.java:331)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
at org.junit.vintage.engine.execution.RunnerExecutor.execute(RunnerExecutor.java:42)
at org.junit.vintage.engine.VintageTestEngine.executeAllChildren(VintageTestEngine.java:80)
at org.junit.vintage.engine.VintageTestEngine.execute(VintageTestEngine.java:72)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:107)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:88)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.lambda$execute$0(EngineExecutionOrchestrator.java:54)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.withInterceptedStreams(EngineExecutionOrchestrator.java:67)
at org.junit.platform.launcher.core.EngineExecutionOrchestrator.execute(EngineExecutionOrchestrator.java:52)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:114)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:86)
at org.junit.platform.launcher.core.DefaultLauncherSession$DelegatingLauncher.execute(DefaultLauncherSession.java:86)
at org.junit.platform.launcher.core.SessionPerRequestLauncher.execute(SessionPerRequestLauncher.java:53)
at org.eclipse.test.EclipseTestRunner.runTests(EclipseTestRunner.java:226)
at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:202)
at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:52)
at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:35)
at org.eclipse.test.CoreTestApplication.start(CoreTestApplication.java:43)
at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:203)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:136)
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:104)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:402)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:659)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:596)
at org.eclipse.equinox.launcher.Main.run(Main.java:1467)
at org.eclipse.equinox.launcher.Main.main(Main.java:1440)
at org.eclipse.core.launcher.Main.main(Main.java:44)
Activity
jukzi commentedon May 23, 2022
also
https://download.eclipse.org/eclipse/downloads/drops4/I20220520-1800/testresults/html/org.eclipse.core.tests.resources_ep424I-unit-win32-java11_win32.win32.x86_64_11.html
jukzi commentedon Aug 30, 2022
also
https://download.eclipse.org/eclipse/downloads/drops4/I20220828-1800/testresults/html/org.eclipse.core.tests.resources_ep425I-unit-win32-java11_win32.win32.x86_64_11.html
jukzi commentedon Aug 30, 2022
can be locally reproduced with
Thread.sleep(200)
at org.eclipse.core.internal.resources.ResourceException.provideStackTrace(String, Throwable)
jukzi commentedon Aug 30, 2022
It is some multi threading problem: if the whole VM is suspended at org.eclipse.core.internal.resources.ResourceTree.standardMoveProject(IProject, IProjectDescription, int, IProgressMonitor)
and only main thread is resumed, then the test passes.
if otherwise only the main thread is suspended there then the test fails.
fix random failing BasicAliasTest.testBug256837 eclipse-platform#95
mickaelistria commentedon Aug 31, 2022
Looking at the proposed patch, it's unclear to me whether the issue is the test, or the aliasManager that doesn't work as expected... Has this test always been failing (even several years ago), or did it start failing recently because of some side-effect of another change (ie this would be a regression)?
jukzi commentedon Aug 31, 2022
I don't know how long it failed. It might only became obvious as hardware or software became faster or slower.
mickaelistria commentedon Aug 31, 2022
So indeed, there is a RefreshJob running at some point in another thread, and the success or failure depends on whether this job has completed before next instruction.
Here is the stack that triggers the RefreshJob (from main thread)
In an ideal world, the "move" opreation wouldn't require to refresh the content, as we do already have some pointers to this content. It would be great to investigate that particular case: if we can get rid of the need to
refresh()then it would fix this tests (and maybe other that are of the same kind).jukzi commentedon Aug 31, 2022
So moving the project does currently not move the .project file but write the .project with the lineseperator configured in the .project file - which does not exist yet. So the configured lineseperator may even be wrong/forgotten? it should be remembered in memory (or binary move the file instead) -> no File.getLineSeparator necessary -> no error -> no refresh -> no fail
mickaelistria commentedon Sep 1, 2022
It's only in this particular cases (with links and different FileStore I believe) that the failure happens. The issue is not really about reading the lineSeparator, after all it's OK to try to read a line separator and to try to refresh asynchronously some content on access.
I see 2 possible issues:
exists()but not asisSynchronized(). If we could have the file synchronized at this stage, then there wouldn't be issue with async refresh.move()operation doesn't send a notification here. Just like creating a new project, I think it's OK to expect a synchronous POST_CHANGE notification. Then the AliasManager would update without need to wait for a separate refresh job to complete.I think it's more the other way round, if there is no refresh, then the test fails (because there was no POST_CHANGE notification.
mickaelistria commentedon Sep 1, 2022
Actually, I'm wrong and you're right: the POST_CHANGE is sent (good), AliasManager is updated (good), but then the RefreshJob triggers (because of lineSeparator and ResourcesPlugin.PREF_LIGHTWEIGHT_AUTO_REFRESH set to true), so the data from AliasManager is temporarily incorrect at the time test asks for it.
What about setting
ResourcesPlugin.PREF_LIGHTWEIGHT_AUTO_REFRESHtofalsefor that test then, so we disable the RefreshJob and have good control over the flow?jukzi commentedon Sep 1, 2022
+1 if that makes the test fail reproducible
BTW how to move a project with the UI? is that even a possible usecase?
laeubi commentedon Sep 1, 2022
Goto Package Explorer > Rightclick > Refactor > Move
fix random failing BasicAliasTest.testBug256837 eclipse-platform#95
fix random failing BasicAliasTest.testBug256837 eclipse-platform#95
[-]random failing org.eclipse.core.tests.internal.alias.BasicAliasTest.testBug256837[/-][+]AliasManager not thread-safe (causes random failing org.eclipse.core.tests.internal.alias.BasicAliasTest.testBug256837 )[/+]jukzi commentedon Sep 5, 2022
InstanceScope.INSTANCE.getNode(ResourcesPlugin.PI_RESOURCES)
.putBoolean(ResourcesPlugin.PREF_LIGHTWEIGHT_AUTO_REFRESH, false);
does not make the test fail :-(
mickaelistria commentedon Sep 7, 2022
I suggest #156 which I hope can improve this in general without need to tweak test.
jukzi commentedon Oct 4, 2022
also
https://download.eclipse.org/eclipse/downloads/drops4/I20221003-1800/testresults/html/org.eclipse.core.tests.resources_ep426I-unit-win32-java11_win32.win32.x86_64_11.html
mickaelistria commentedon Oct 4, 2022
The patch did suffice for 25 days; that's a relative success! I'll try to look at further issues later.
jukzi commentedon Jun 13, 2023
recent fail:
jukzi commentedon Jun 27, 2024
https://download.eclipse.org/eclipse/downloads/drops4/I20240626-1800/testresults/html/org.eclipse.core.tests.resources_ep433I-unit-win32-java17_win32.win32.x86_64_17.html
trancexpress commentedon Oct 26, 2026
Another failure here: https://download.eclipse.org/eclipse/downloads/drops4/I20261025-2300/testresults/html/org.eclipse.core.tests.resources_ep442I-unit-win32-x86_64-java25_win32.win32.x86_64_25.html
Workspace log: https://download.eclipse.org/eclipse/downloads/drops4/I20261025-2300/testresults/ep442I-unit-win32-x86_64-java25_win32.win32.x86_64_25/org.eclipse.core.tests.resources.AutomatedResourceTests.txt
With the change mentioned here I can reproduce the fail fairly often: #95 (comment)
With also this change on top I can no longer reproduce the fail: #3042
So lets add a wait for auto-refresh to the test and keep this ticket open, until a solution for the race conditions in
AliasManageris found. Potentially the test will continue to fail due to these.Wait for refresh job in BasicAliasTest.testBug256837