Community
Participate
Working Groups
The following test has started failing more frequently now and what's worse fails in two different OSes (failed on windows, Linux JRE 8 and JRE 9): Index File should not have got modified expected:<1525933670774> but was:<1525933671675> junit.framework.AssertionFailedError: Index File should not have got modified expected:<1525933670774> but was:<1525933671675> at org.eclipse.jdt.core.tests.model.JavaIndexTests.testNonExistentIndexRestart(JavaIndexTests.java:319)
Some observations: During getJavaModel().refreshExternalArchives(null,null); we hit the code block in DeltaProcessor.java:1051, where upon detecting equal time stamps we still request to index the given library. This block was introduced via bug 356620 but I could not find any specific explanation in the bug. If I comment that code block we still issue an indexing request, now from waitUntilIndexesReady(); I'm looking at this stack trace: AddJarFileToIndex.<init>(IPath, IndexLocation, IndexManager, boolean) line: 73 IndexManager.getRequest(Object, IPath, IndexLocation, IndexManager, boolean) line: 598 IndexManager.rebuildIndex(IndexLocation, IPath, boolean) line: 748 IndexManager.rebuildIndex(IndexLocation, IPath) line: 725 IndexManager.getIndex(IPath, IndexLocation, boolean, boolean) line: 321 IndexManager.getIndexes(IndexLocation[], IProgressMonitor) line: 408 PatternSearchJob.getIndexes(IProgressMonitor) line: 93 PatternSearchJob.ensureReadyToRun() line: 56 IndexManager(JobManager).performConcurrentJob(IJob, int, IProgressMonitor) line: 174 BasicSearchEngine.searchAllTypeNames(char[], int, char[], int, int, IJavaSearchScope, IRestrictedAccessTypeRequestor, int, IProgressMonitor) line: 1848 SearchEngine.searchAllTypeNames(char[], int, char[], int, int, IJavaSearchScope, TypeNameRequestor, int, IProgressMonitor) line: 1097 AbstractJavaModelTests.waitUntilIndexesReady() line: 3429 JavaIndexTests.testNonExistentIndexRestart() line: 323 In PatternSearchJob.getIndexes() I see two indexLocations, and further down getIndexStates().get(indexLocation) for one of the locations yields null. Maybe it shouldn't?
Created attachment 274783 [details] WIP during debug session @Manoj, this is a dump of my current state during debugging. Maybe it helps you to take this to completion? Changes in tests allow to run the affected test in a loop, to increase probability of the problem hitting. I see it failing mostly in iteration 0, but also a few non-failing iterations happen once in a while. Debug-flag FileIndexLocation.cryOnWrite helps to identify when an index is written during that part of the test which shouldn't. PS: I started looking into this because for the first time (?) I saw also a gerrit job fail due to this issue, which creates extra churn during development...
Failed again in the latest build: https://download.eclipse.org/eclipse/downloads/drops4/I20190307-0500/testresults/html/org.eclipse.jdt.core.tests.model_ep411I-unit-cen64-gtk3-java11_linux.gtk.x86_64_11.html
Failed again at https://download.eclipse.org/eclipse/downloads/drops4/I20190904-2200/testresults/html/org.eclipse.jdt.core.tests.model_ep413I-unit-mac64-java8_macosx.cocoa.x86_64_8.0.html
Bulk move out of 4.14
No time for this - moving it out
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
