Community
Participate
Working Groups
Version: 4.2.0 Build id: I20120608-1400 testBug376673e test is failed with JDK8 on solaris: Unexpected search results. ----------- Expected ------------ lib376673.jar p.i.Test [No source] EXACT_MATCH ------------ but was ------------ --------- Difference is ---------- expected:<[lib376673.jar p.i.Test [No source] EXACT_MATCH]> but was:<[]> junit.framework.ComparisonFailure: Unexpected search results. ----------- Expected ------------ lib376673.jar p.i.Test [No source] EXACT_MATCH ------------ but was ------------ --------- Difference is ---------- expected:<[lib376673.jar p.i.Test [No source] EXACT_MATCH]> but was:<[]> at org.eclipse.jdt.core.tests.junit.extension.TestCase.assertStringEquals(TestCase.java:230) at org.eclipse.jdt.core.tests.junit.extension.TestCase.assertEquals(TestCase.java:206) at org.eclipse.jdt.core.tests.model.AbstractJavaSearchTests.assertSearchResults(AbstractJavaSearchTests.java:725) at org.eclipse.jdt.core.tests.model.AbstractJavaSearchTests.assertSearchResults(AbstractJavaSearchTests.java:683) at org.eclipse.jdt.core.tests.model.AbstractJavaSearchTests.assertSearchResults(AbstractJavaSearchTests.java:680) at org.eclipse.jdt.core.tests.model.JavaSearchBugsTests2.testBug376673e(JavaSearchBugsTests2.java:619) at org.eclipse.jdt.core.tests.model.SuiteOfTestCases$Suite.runTest(SuiteOfTestCases.java:100) at org.eclipse.jdt.core.tests.model.SuiteOfTestCases$Suite.superRun(SuiteOfTestCases.java:84) at org.eclipse.jdt.core.tests.model.SuiteOfTestCases$1.protect(SuiteOfTestCases.java:72) at org.eclipse.jdt.core.tests.model.SuiteOfTestCases$Suite.run(SuiteOfTestCases.java:81) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:501) at org.eclipse.test.EclipseTestRunner.run(EclipseTestRunner.java:259) at org.eclipse.test.CoreTestApplication.runTests(CoreTestApplication.java:36) at org.eclipse.test.CoreTestApplication.run(CoreTestApplication.java:32) at org.eclipse.equinox.internal.app.EclipseAppContainer.callMethodWithException(EclipseAppContainer.java:587) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:198) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:353) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:180) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:629) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at org.eclipse.equinox.launcher.Main.run(Main.java:1438) at org.eclipse.equinox.launcher.Main.main(Main.java:1414) at org.eclipse.core.launcher.Main.main(Main.java:34) Steps to Reproduce: Use eclipse-Automated-Tests-4.2 to run automated tests with jdk8. 1. Install jdk8 from http://jdk8.java.net/download.html 2. Run jdtcoremodel tests
I don't see this problem with R4_2. But then I tried it on a windows machine as I don't have access to a Solaris environment. Could you try running the tests on a 4.3 test bundle?
*** Bug 516542 has been marked as a duplicate of this bug. ***
Got this in linux as well: see bug 516452 comment 0
(In reply to Manoj Palat from comment #3) > Got this in linux as well: > > see bug 516452 comment 0 Corrected : bug 516542 comment 0
*** Bug 516543 has been marked as a duplicate of this bug. ***
(In reply to Manoj Palat from comment #5) > *** Bug 516543 has been marked as a duplicate of this bug. *** 516453 indeed is the right bug Noting that locally on a windows machine this passes and the failure is not consistent - intermittent at best - not a blocker for 4.7M7
(In reply to Manoj Palat from comment #6) > (In reply to Manoj Palat from comment #5) > > *** Bug 516543 has been marked as a duplicate of this bug. *** > > 516453 indeed is the right bug > > Noting that locally on a windows machine this passes and the failure is not > consistent - intermittent at best - not a blocker for 4.7M7 failed for the RC2 candidate also http://download.eclipse.org/eclipse/downloads/drops4/I20170524-2000/testresults/html/org.eclipse.jdt.core.tests.model_ep47I-unit-cen64-gtk3_linux.gtk.x86_64_8.0.html though passed for the gtk2 http://download.eclipse.org/eclipse/downloads/drops4/I20170524-2000/testresults/html/org.eclipse.jdt.core.tests.model_ep47I-unit-cen64-gtk2_linux.gtk.x86_64_8.0.html
Failed again on two platforms: http://download.eclipse.org/eclipse/downloads/drops4/I20170606-0800/testResults.php Manoj, please take a closer look.
(In reply to Dani Megert from comment #8) > Failed again on two platforms: Both Linux but different GTK+ version.
(In reply to Dani Megert from comment #9) > (In reply to Dani Megert from comment #8) > > Failed again on two platforms: > > Both Linux but different GTK+ version. On a local centos vm setup both the testss (see bug 516542 as well) passed - in all cases where it was run individually and by AJM together - failure not reproducible. need to investigate more
(In reply to Manoj Palat from comment #10) > (In reply to Dani Megert from comment #9) > > (In reply to Dani Megert from comment #8) > > > Failed again on two platforms: > > > > Both Linux but different GTK+ version. > > On a local centos vm setup both the testss (see bug 516542 as well) passed - > in all cases where it was run individually and by AJM together - failure not > reproducible. need to investigate more Under investigation - not a blocker - moving to 4.8M1
Bulk move out of 4.9
#failures in JDT/Core tests is approaching the magic zero, this bug being the last remaining on platforms <= 1.8. Care to give some priority to this?
(In reply to Stephan Herrmann from comment #13) > #failures in JDT/Core tests is approaching the magic zero, this bug being > the last remaining on platforms <= 1.8. > > Care to give some priority to this? Sure. re-targeting to 4.10 to be on the radar
New Gerrit change created: https://git.eclipse.org/r/132307
Gerrit change https://git.eclipse.org/r/132307 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=8e07adc33a188e18e495d33021672ea64fc0668e
New Gerrit change created: https://git.eclipse.org/r/132498
Gerrit change https://git.eclipse.org/r/132498 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=e806c1bd197e74293615d1ceb885b332b0a30e13
New Gerrit change created: https://git.eclipse.org/r/132882
Outputs from build: https://download.eclipse.org/eclipse/downloads/drops4/I20181121-1800/testresults/ep410I-unit-cen64-gtk3_linux.gtk.x86_64_8.0/org.eclipse.jdt.core.tests.model.AllJavaModelTests.txt Test testBug376673e about to fail, listing extra debug info LANG env variable: null Listing markers of test project Resolved classpath entries for test project: /P/lib376673.jar[CPE_LIBRARY][K_BINARY][isExported:false] /home/cbi/genie.releng/workspace/ep410I-unit-cen64-gtk3/workarea/I20181121-1800/eclipse-testing/test-eclipse/eclipse/jdt_model_folder/jclMin1.7.jar[CPE_LIBRARY][K_BINARY][isExported:false] All classpath entries for test project: /P/lib376673.jar[CPE_LIBRARY][K_BINARY][isExported:false] /home/cbi/genie.releng/workspace/ep410I-unit-cen64-gtk3/workarea/I20181121-1800/eclipse-testing/test-eclipse/eclipse/jdt_model_folder/jclMin1.7.jar[CPE_LIBRARY][K_BINARY][isExported:false] Printing Java elements of Java project: P (not open) Listing contents of jar file: /home/cbi/genie.releng/workspace/ep410I-unit-cen64-gtk3/workarea/I20181121-1800/eclipse-testing/test-eclipse/eclipse/jdt_model_folder/data/P/lib376673.jar Listing contents of zip entry: p?/i?/Test.class // Compiled from Test.java (version 1.7 : 51.0, super bit) public class p?.i?.Test { // Method descriptor #6 ()V // Stack: 1, Locals: 1 public Test(); 0 aload_0 [this] 1 invokespecial java.lang.Object() [8] 4 return Line numbers: [pc: 0, line: 2] Local variable table: [pc: 0, pc: 5] local: this index: 0 type: p?.i?.Test } testBug376673e got no result! On first glance this means we don't have a LANG variable set, which uses default encoding, which is not necessarily UTF-8. However, when running the test with "bad" contents in the LANG env variable on my machine, all of the tests for bug 376673 failed. I've created https://git.eclipse.org/r/#/c/132882/, in which the extra outputs will be printed always. This should tell us what the gerrit environment has; the test doesn't fail in this environment.
Results from gerrit job: https://git.eclipse.org/r/#/c/132882/ 09:43:59 [2018-11-22 03:43:59 -0500] org.eclipse.jdt.core.tests.model.JavaSearchBugsTests2#testBug376673e() 09:44:00 Test testBug376673e about to validate, listing extra debug info 09:44:00 LANG env variable: en_US.UTF-8 09:44:00 Listing markers of test project 09:44:00 Resolved classpath entries for test project: 09:44:00 /P/lib376673.jar[CPE_LIBRARY][K_BINARY][isExported:false] 09:44:00 /jobs/genie.jdt/eclipse.jdt.core-Gerrit/workspace/org.eclipse.jdt.core.tests.model/target/work/jclMin1.7.jar[CPE_LIBRARY][K_BINARY][isExported:false] 09:44:00 All classpath entries for test project: 09:44:00 /P/lib376673.jar[CPE_LIBRARY][K_BINARY][isExported:false] 09:44:00 /jobs/genie.jdt/eclipse.jdt.core-Gerrit/workspace/org.eclipse.jdt.core.tests.model/target/work/jclMin1.7.jar[CPE_LIBRARY][K_BINARY][isExported:false] 09:44:00 Printing Java elements of Java project: P 09:44:00 lib376673.jar 09:44:00 <default> (not open) 09:44:00 p𠮟.i𠮟 (...) 09:44:00 p𠮟 (not open) 09:44:00 /jobs/genie.jdt/eclipse.jdt.core-Gerrit/workspace/org.eclipse.jdt.core.tests.model/target/work/jclMin1.7.jar (not open) 09:44:00 Listing contents of jar file: /jobs/genie.jdt/eclipse.jdt.core-Gerrit/workspace/org.eclipse.jdt.core.tests.model/target/work/data/P/lib376673.jar 09:44:00 Listing contents of zip entry: p𠮟/i𠮟/Test.class 09:44:00 // Compiled from Test.java (version 1.7 : 51.0, super bit) 09:44:00 public class p𠮟.i𠮟.Test { 09:44:00 09:44:00 // Method descriptor #6 ()V 09:44:00 // Stack: 1, Locals: 1 09:44:00 public Test(); 09:44:00 0 aload_0 [this] 09:44:00 1 invokespecial java.lang.Object() [8] 09:44:00 4 return 09:44:00 Line numbers: 09:44:00 [pc: 0, line: 2] 09:44:00 Local variable table: 09:44:00 [pc: 0, pc: 5] local: this index: 0 type: p𠮟.i𠮟.Test 09:44:00 } So looks like the build environment is bad. I don't know why *only* one of the tests with UTF-8 characters fails; I would expect all of them to fail. But maybe the default encoding on CentOS is different than the one in our environment. I'll check how this goes in my CentOS VM. No idea about changing the build environment though. Andrey?
I ran the test case in my CentOS VM. Per default, the LANG env variable is set to US UTF-8, so the test passes. When I run Eclipse after unsetting the LANG env variable, all the tests for bug 376673 in JavaSearchBugsTests2 failed. So I have no idea how the build machine is configured so that only one of those tests fail. I suggest to set the LANG variable to en_US.UTF-8, at least for the platform tests.
Just a random guess from seeing the influence of char encodings: maybe -Dsun.jnu.encoding is also relevant? See bug 516542 comment 7 and onward.
I made a few attempts at tweaking an environment to produce the same behavior as the CentOS test machine but failed. Next I was curious about this stanza: if ("macosx".equals(System.getProperty("osgi.os"))) { return; } brought in via https://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=3b08272ee847aa9d892ea0105ce6d34424762f9c with no real explanation. (Does any owner of a mac want to test what happens if you enable those tests?) To me it seems we are overzealously testing a weakly defined situation. So, what do people think about simply short-cutting this test if getenv("LANG") == null?
(In reply to Stephan Herrmann from comment #24) > To me it seems we are overzealously testing a weakly defined situation. > > So, what do people think about simply short-cutting this test if > getenv("LANG") == null? Sounds OK to me. Especially if we are sure the code review verification jobs (gerrit as of now) will always be configured correctly and so will always run the test.
New Gerrit change created: https://git.eclipse.org/r/133579
(In reply to Stephan Herrmann from comment #24) > So, what do people think about simply short-cutting this test if > getenv("LANG") == null? The environment issue with missing LANG can not only affect this particular test, so I've created bug 542454. I'm monitoring official build results and I see how "volatile" they are. One part of the problem can be wrong / unexpected environment. I think we should let the test fail (it fails constantly since a year or so), but explicitly mention WHY the test fail (unexpected environment).
(In reply to Andrey Loskutov from comment #27) > (In reply to Stephan Herrmann from comment #24) > > > So, what do people think about simply short-cutting this test if > > getenv("LANG") == null? > > The environment issue with missing LANG can not only affect this particular > test, so I've created bug 542454. Thanks! > I'm monitoring official build results and I see how "volatile" they are. After some slack we are gradually getting closer to zero failures again in org.eclipse.jdt.core.tests.* across all platforms, let's do it! :)
Gerrit change https://git.eclipse.org/r/133579 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=be463b257a9ef835177ce02bc0b5d07c11cdec60
Bug 542492 is fixed now, the test didn't fail in the first build since the fixed genie environment: https://download.eclipse.org/eclipse/downloads/drops4/I20181219-1800/testResults.php I suggest closing this as fixed.
New Gerrit change created: https://git.eclipse.org/r/134987
(In reply to Simeon Andreev from comment #30) > Bug 542492 is fixed now, the test didn't fail in the first build since the > fixed genie environment: > > https://download.eclipse.org/eclipse/downloads/drops4/I20181219-1800/ > testResults.php > > I suggest closing this as fixed. There is now a fail on Windows (finally we see Windows test results!). I've pushed another patch.
Gerrit change https://git.eclipse.org/r/134987 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=9420ac111fc8ea1b1513fabd25db66ee1359accd
Windows failure is now fixed with: https://download.eclipse.org/eclipse/downloads/drops4/I20190112-1800/testresults/html/org.eclipse.jdt.core.tests.model_ep411I-unit-win32_win32.win32.x86_64_8.0.html
Verified for 4.11 M3 using build I20190219-1800.
