On 23.10.2017 14:14, Paul King wrote:
[...]
They all run fine for me locally but currently the oraclejdk9 builds are
bombing out on the CI server during the generateGrammarSource task (the
Antlr plugin):
https://travis-ci.org/apache/groovy/builds/291471224
what I see there is:
Caused by: org.gradle.process.internal.ExecException: Process 'Gradle ANTLR
Worker 2' finished with non-zero exit value 137
at
org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:369)
at
org.gradle.process.internal.worker.DefaultWorkerProcess.waitForStop(DefaultWorkerProcess.java:190)
at
org.gradle.process.internal.worker.DefaultWorkerProcessBuilder$MemoryRequestingWorkerProcess.waitForStop(DefaultWorkerProcessBuilder.java:228)
at
org.gradle.process.internal.worker.DefaultSingleRequestWorkerProcessBuilder$1.invoke(DefaultSingleRequestWorkerProcessBuilder.java:118)
... 91 more
BUILD FAILED
Total time: 1 mins 52.505 secs
Publishing build information...
https://gradle.com/s/apqc2iu7ft74u
Stopped 1 worker daemon(s).
Received result Failure[value=org.gradle.initialization.ReportedException:
org.gradle.internal.exceptions.LocationAwareException: Execution failed for
task ':generateGrammarSource'.] from daemon DaemonInfo{pid=3192,
address=[5320ada0-f54f-43d7-a69c-0a6ac21b7748 port:41001,
addresses:[/0:0:0:0:0:0:0:1, /127.0.0.1]], state=Busy, lastBusy=1508754740834,
context=DefaultDaemonContext[uid=2cf5e2d2-f46d-4d2e-b63d-ccd36263ed46,javaHome=/usr/lib/jvm/java-9-oracle,daemonRegistryDir=/home/travis/.gradle/daemon,pid=3192,idleTimeout=120000,daemonOpts=-Xmx1G,-Dfile.encoding=UTF-8,-Duser.country=US,-Duser.language=en,-Duser.variant,-ea]}
(build should be done).
And that means to me we have a worker that fails and no real hint as of
how the worker daemon failed.
If anyone has any thoughts on why, I'd be keen to hear from you or
confirmation on which environments it works/doesn't work.
According to
https://stackoverflow.com/questions/38967991/why-are-my-gradle-builds-dying-with-exit-code-137
it could be a OOME. Then it would be travis killing the daemon because
it consumes too much memory.
There are a handful of places where a test or part of a test that is
broken on jdk9 is currently skipped over (normally has FIX_JDK9 in a
comment nearby). We obviously want to get rid of all of those before
final releases of 2_6 or 3_0 but at least with a green build now on jdk9
we should be able to stop any new errors being added to the list. Happy
for any help getting rid of any of the FIX_JDK9 hacks.
I have to take a look what these are
bye Jochen
