BuildpathTests.testChangeZIPArchive1 fails

[jukzi]

recently that tests often fails CI:

junit.framework.ComparisonFailure: 
Invalid problem(s)!!!.
----------- Expected ------------
Problem : The method foo() is undefined for the type X [ resource : </Project/q/Y.java> range : <54,57> category : <50> severity : <2>]
------------ but was ------------

---------------------- ----------
 expected:<[Problem : The method foo() is undefined for the type X [ resource : </Project/q/Y.java> range : <54,57> category : <50> severity : <2>]]> but was:<[]>
    at org.eclipse.jdt.core.tests.junit.extension.TestCase.assertStringEquals(TestCase.java:265)
    at org.eclipse.jdt.core.tests.junit.extension.TestCase.assumeEquals(TestCase.java:285)
    at org.eclipse.jdt.core.tests.builder.BuilderTests.expectingProblemsFor(BuilderTests.java:350)
    at org.eclipse.jdt.core.tests.builder.BuilderTests.expectingProblemsFor(BuilderTests.java:343)
    at org.eclipse.jdt.core.tests.builder.BuildpathTests.testChangeZIPArchive1(BuildpathTests.java:402)

[jukzi]

can not reproduce locally on win

[subyssurendran666]

Tracing from the Run Configuration may allow us to reproduce the test failure (I have tested this on a Mac). I'm not sure which options should be enabled in org.eclipse.jdt.core. Please see the screenshot; these five options worked in my scenario. Additionally, I consistently experienced BuildpathTests failures a couple of days ago, but they are working fine now.

[srikanth-sankaran]

May be we should disable this darned test!

[stephan-herrmann]

Tracing from the Run Configuration may allow us to reproduce the test failure (I have tested this on a Mac). I'm not sure which options should be enabled in org.eclipse.jdt.core. Please see the screenshot; these five options worked in my scenario. Additionally, I consistently experienced BuildpathTests failures a couple of days ago, but they are working fine now.

@subyssurendran666 are you saying that enabling these options allowed you to reproduce the problem locally? I tried the same (on linux) but didn't see the failure.

If you are able to reproduce (even if only occasionally) please enable a few more tracing options, particularly around buffermanager, builder, javadelta and javamodel (incl. suboptions). Once you see the failure, please capture the tracing output and attach it to this issue. TIA.

If still we fail to reproduce locally, perhaps the test could programmatically enable those tracing options, e.g.:

org.eclipse.jdt.internal.core.builder.JavaBuilder.DEBUG = true;
try {
   // run the test
} finally {
    org.eclipse.jdt.internal.core.builder.JavaBuilder.DEBUG = true;
}

And we'd keep that test harness until it provides us the desired information, wdyt?

[subyssurendran666]

Tracing from the Run Configuration may allow us to reproduce the test failure (I have tested this on a Mac). I'm not sure which options should be enabled in org.eclipse.jdt.core. Please see the screenshot; these five options worked in my scenario. Additionally, I consistently experienced BuildpathTests failures a couple of days ago, but they are working fine now.

@subyssurendran666 are you saying that enabling these options allowed you to reproduce the problem locally? I tried the same (on linux) but didn't see the failure.

If you are able to reproduce (even if only occasionally) please enable a few more tracing options, particularly around buffermanager, builder, javadelta and javamodel (incl. suboptions). Once you see the failure, please capture the tracing output and attach it to this issue. TIA.

If still we fail to reproduce locally, perhaps the test could programmatically enable those tracing options, e.g.:

org.eclipse.jdt.internal.core.builder.JavaBuilder.DEBUG = true;
try {
   // run the test
} finally {
    org.eclipse.jdt.internal.core.builder.JavaBuilder.DEBUG = true;
}

And we'd keep that test harness until it provides us the desired information, wdyt?

Sure @stephan-herrmann