groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jochen Theodorou <>
Subject Re: travis-ci changes
Date Tue, 24 Oct 2017 06:02:10 GMT
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):

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(
> at org.gradle.process.internal.worker.DefaultWorkerProcess.waitForStop(
> at org.gradle.process.internal.worker.DefaultWorkerProcessBuilder$MemoryRequestingWorkerProcess.waitForStop(
> at org.gradle.process.internal.worker.DefaultSingleRequestWorkerProcessBuilder$1.invoke(
> ... 91 more
> Total time: 1 mins 52.505 secs
> Publishing build information...
> 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, /]], state=Busy, lastBusy=1508754740834,
(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

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

View raw message