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.