Search in 4.30 sometimes finds nothing

[cdietrich]

Xtexts Xbase content assist uses jdt search to provide proposals for jdt tyes
beginning with 4.30 we see regular test fails in
mwe

eclipse-mwe/mwe#270

here are the trace logs for good and bad testcase

goodcase.txt
badcase.txt

i have no clue how to start investigating

[LorenzoBettini]

Anyone from JDT?
Can that be related to some synchronization issues introduced in JDT recently (some of which I helped reverting)?

[iloveeclipse]

I believe there were some refactorings in the search code, @jukzi : could you please check if they were done in 4.30 time frame?

@cdietrich, @LorenzoBettini : could you try to provide stable test case that would fail? Or test setup that would reproduce the problem more reliably as "sometimes"?

[LorenzoBettini]

@iloveeclipse Unfortunately that's the real problem: it happens sometimes and in the CI :'(

[jukzi]

I am not aware of any search refactorings in JDT where i was involved.

[LorenzoBettini]

@iloveeclipse some more context: in our UI tests we create projects programmatically. Doing that inside or outside a WorkspaceModifyOperation doesn't help. Maybe doing that within a WorkspaceModifyOperation seems to increase the chance of failures.

[iloveeclipse]

Just in case, are you running with this option: -DDetectVMInstallationsJob.disabled=true? In 4.29 there was eclipse-jdt/eclipse.jdt.debug#231 that added automatic JVM detection, and that beast resets JVM's on startup at random times, so we had to change all tests to use this argument, see links to the original PR.

If you don't use this option, please add it.

It would be at least nice to know when exactly the problems started. Was it really 4.30 or maybe 4.29? If 4.30, was it M1, M2, M3?

Beside this, JobManager changes could be related, but they also were done already in 4.29:

• eb3285b
• 664688d

[LorenzoBettini]

@iloveeclipse I remember I immediately hated that feature in my Eclipse installations, but we never disabled that for tests.

Something like this LorenzoBettini/xtext@428c1e6 should disable it globally right?

[iloveeclipse]

Something like this LorenzoBettini/xtext@428c1e6 should disable it globally right?

I have a very little understanding about maven / tycho / surefire settings and which one need to be touched to get the desired effect. Add an assert in the test for the VM option (system property) to be set & you will see it.

[LorenzoBettini]

@iloveeclipse adding that option in .mvn/maven.config doesn't change anything; as you said, maybe we should pass it directly to the test plugin.

I see two occurrences in jdt.core

eclipse.jdt.core/org.eclipse.jdt.core.tests.model/pom.xml

Line 35 in 75ade7e

<argLine>-Xmx1G -Djdt.default.test.compliance=1.8 -DDetectVMInstallationsJob.disabled=true ${tycho.surefire.argLine}</argLine>

and

eclipse.jdt.core/org.eclipse.jdt.apt.tests/pom.xml

Line 36 in 75ade7e

<DetectVMInstallationsJob.disabled>true</DetectVMInstallationsJob.disabled>

I'd say the second one is "more" standard. I'll try that

[jukzi]

Just in case, are you running with this option: -DDetectVMInstallationsJob.disabled=true?

don't waste your time on that - that problem was solved with eclipse-jdt/eclipse.jdt.debug#293

[iloveeclipse]

Just in case, are you running with this option: -DDetectVMInstallationsJob.disabled=true?

don't waste your time on that - that problem was solved with eclipse-jdt/eclipse.jdt.debug#293

Are you sure? That was only for the pure jdt core tests that didn't require launching plugin. If MWE/Xtext require it, the job is scheduled.

[jukzi]

I am sure (but still human error prone).
jdt.core itself has multiple random failing tests that sometimes have the same issue of sometimes not finding everything expected. Does not make much sense to analyze downstream projects as long as this random fails are not fixed within JDT.

[LorenzoBettini]

@iloveeclipse @jukzi That option seems to do something: eclipse-xtext/xtext#3063

flakes are less, and they usually succeed after the first attempt.
Build time seems to also have decreased (by a small amount, so it might also be an impression).

It looks like there are still synchronization problems, which shouldn't be there, but at least that job detecting JVM doesn't seem to disturb anymore.

[iloveeclipse]

@LorenzoBettini : thanks.
I assume we can close this issue for now, especially we don't have a reproducer to work on. Feel free to open a new ticket if you have more fails or more data.

[LorenzoBettini]

@iloveeclipse In any case; it would be really helpful to have some guidelines on how to properly synchronize with jobs of this kind...

[iloveeclipse]

@LorenzoBettini : for search, index state is important, so you could do something like
JavaModelManager.getIndexManager().waitForIndex(true, monitor);

Or more complex example:

eclipse.jdt.core/org.eclipse.jdt.core.tests.model/src/org/eclipse/jdt/core/tests/model/AbstractJavaModelTests.java

Lines 4064 to 4090 in 75ade7e

	public void waitUntilIndexesReady() {
	// dummy query for waiting until the indexes are ready
	SearchEngine engine = new SearchEngine();
	IJavaSearchScope scope = SearchEngine.createWorkspaceScope();
	try {
	JavaModelManager.getIndexManager().waitForIndex(isIndexDisabledForTest(), null);
	engine.searchAllTypeNames(
	null,
	SearchPattern.R_EXACT_MATCH,
	"!@$#!@".toCharArray(),
	SearchPattern.R_PATTERN_MATCH | SearchPattern.R_CASE_SENSITIVE,
	IJavaSearchConstants.CLASS,
	scope,
	new TypeNameRequestor() {
	public void acceptType(
	int modifiers,
	char[] packageName,
	char[] simpleTypeName,
	char[][] enclosingTypeNames,
	String path) {}
	},
	IJavaSearchConstants.WAIT_UNTIL_READY_TO_SEARCH,
	null);
	} catch (CoreException e) {
	logError("exception occurred while waiting on indexing", e);
	}
	}

[LorenzoBettini]

@iloveeclipse Thanks!
I think @cdietrich already tried that (eclipse-mwe/mwe#270 (comment)) but without success... maybe now that the JVM job is disabled, things might improve by waiting for the index.