Community
Participate
Working Groups
Lots of gerrit tests in JDT/Core are failing since https://ci.eclipse.org/jdt/job/eclipse.jdt.core-Gerrit/376/ due to unexpected output: Picked up JAVA_TOOL_OPTIONS: -Xmx2G -Djava.io.tmpdir=/tmp/genie.jdt This seems to be produced unconditionally from jdk-9_x64-latest/bin/java (Is that file a script??).
We added the JAVA_TOOL_OPTIONS environment variable to the systemd start script for Hudson/Jenkins today.
(In reply to Frederic Gurr from comment #1) > We added the JAVA_TOOL_OPTIONS environment variable to the systemd start > script for Hudson/Jenkins today. If it's in a systemd start script, how come we see it's output in java applications run from our tests?
All JDK output this line when they see the JAVA_TOOL_OPTIONS env variable. Try for yourself on your local machine.
You can't prevent java to print this line on stderr. The only way is to unset it. If this is the way you want to go, please make sure that you call your java applications with a given -Xmx and and the same java.io.tmpdir as defined in this variable. See https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/envvars002.html https://docs.oracle.com/javase/8/docs/platform/jvmti/jvmti.html#tooloptions The reasoning for setting JAVA_TOOL_OPTIONS on the CI instances is to easily prevent java to define on its own the max heap size. By default, it's something like 25% of the machine RAM. CI instances at Eclipse currently runs on machines with 64GB or 128GB of RAM, making the default value way too high for a shared environment. Setting JAVA_TOOL_OPTIONS is our only way to make the default a more sensible one for every single Java process spawned by builds. Making sure that projects actually pass a sensible value is an impossible task otherwise. Of course, any project can decide to override the default value by specifying a different one on the command line. Thanks.
To be explicit: the problematic situation is when the test suite compiles and runs the SUT. Those tiny programs (typically few tens of LOC) are executed as part of the test and the output (std/err) of those programs is checked. Tens of thousands of these per build. It's not practicable to expect output from Java that is not under our control. OTOH, I'm not concerned about the environment in which the test suite itself is invoked. Apparently, JDT is part of 0.1% that need a very extraordinary solution [1]. Interesting. [1] https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg15266.html
I don’t know how the SUT are started. I guess they use something like ProcrssBuilder. The workaround is then to remove JAVA_TOOL_OPTIONS from the environment map. If you point me to where is the startup code, I cab probably help with a patch.
We have a lot of calls to Runtime.getRuntime().exec() in http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.core.tests.compiler/src/org/eclipse/jdt/core/tests/compiler/regression/AbstractRegressionTest.java More magic is in http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.core.tests.compiler/src/org/eclipse/jdt/core/tests/util/TestVerifier.java http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/tree/org.eclipse.jdt.core.tests.compiler/src/org/eclipse/jdt/core/tests/util/VerifyTests.java
Stephan, the unset attempt didn't work and then I realized the tests probably run in a different instance or a different VM. Should we try to address this in our code? :(
New Gerrit change created: https://git.eclipse.org/r/116616
https://git.eclipse.org/r/116616 is an initial version of what I see as a workaround. Please note that I don't have any dev env set on the current machine, so this code has been written without any compiler / ide. It will certainly not compile.
Gerrit change https://git.eclipse.org/r/116616 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=21414b73c99f6c67b090931395d11db67cbb554e
(In reply to Mikaël Barbero from comment #10) > https://git.eclipse.org/r/116616 is an initial version of what I see as a > workaround. > > Please note that I don't have any dev env set on the current machine, so > this code has been written without any compiler / ide. It will certainly not > compile. Nice shot! Only minimal cleanup needed to push this (In reply to Eclipse Genie from comment #11) > Gerrit change https://git.eclipse.org/r/116616 was merged to [master]. > Commit: > http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/ > ?id=21414b73c99f6c67b090931395d11db67cbb554e With this our tests pass again. Thanks, Mikaël!
New Gerrit change created: https://git.eclipse.org/r/116662
Gerrit change https://git.eclipse.org/r/116662 was merged to [R4_7_maintenance]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.core.git/commit/?id=6b020e705ba2669481bde653aefe4e4b18b04efe
The problem exists in jdt.debug, too: https://ci.eclipse.org/jdt/job/eclipse.jdt.debug-Gerrit/142/testReport/junit/org.eclipse.jdt.debug.tests.core/ArgumentTests/testVMArgSimpleQuotes/ Fehlermeldung expected:<[]foo> but was:<[Picked up JAVA_TOOL_OPTIONS: -Xmx2G -Djava.io.tmpdir=/tmp/genie.jdt]foo> Stacktrace junit.framework.ComparisonFailure: expected:<[]foo> but was:<[Picked up JAVA_TOOL_OPTIONS: -Xmx2G -Djava.io.tmpdir=/tmp/genie.jdt]foo> at junit.framework.Assert.assertEquals(Assert.java:100) at junit.framework.Assert.assertEquals(Assert.java:107) at junit.framework.TestCase.assertEquals(TestCase.java:269) at org.eclipse.jdt.debug.tests.core.ArgumentTests.testOutput(ArgumentTests.java:378) at org.eclipse.jdt.debug.tests.core.ArgumentTests.testWithVMArg(ArgumentTests.java:309) at org.eclipse.jdt.debug.tests.core.ArgumentTests.testVMArgSimpleQuotes(ArgumentTests.java:152)
New Gerrit change created: https://git.eclipse.org/r/116732
(In reply to Eclipse Genie from comment #16) > New Gerrit change created: https://git.eclipse.org/r/116732 This patch applies a similar fix, but for ILaunch*
Gerrit change https://git.eclipse.org/r/116732 was merged to [master]. Commit: http://git.eclipse.org/c/jdt/eclipse.jdt.debug.git/commit/?id=bbd4c57de571649da84adc3c9fb108ecd91b974b
Fixes applied in JDT/Core and JDT/Debug tests. Thanks.
