groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Forax <fo...@univ-mlv.fr>
Subject Re: travis-ci changes
Date Tue, 24 Oct 2017 10:20:59 GMT
Maybe it's because if you do not specify a GC, the default GC is not the same between 8 and
9 (CMS vs G1)

G1 tends to consume more memory because it delays the collection to avoid long pause. 

RĂ©mi


On October 24, 2017 8:02:10 AM GMT+02:00, Jochen Theodorou <blackdrag@gmx.org> wrote:
>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

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Mime
View raw message