groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thibault Kruse <>
Subject Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Date Sun, 06 Sep 2015 14:29:30 GMT
I believe this kind of error normally only happens when java in
invoking native C/C++ code.

I could reproduce locally on java-9-oracle 9.0-b78 with either:
./gradlew :groovy-groovysh:test -Pindy=true.

Also I could sometimes reproduce like this:
./gradlew :groovy-console:test -Pindy=true

Running individual test classes only does not seem to reproduce the
error. Reducing the number of tested classes reduces the likelyhood of
the filure occuring (see

Even worse, re-running the command does not guarantee to reproduce the
failure, in particular the console tests were fickle in that respect.
I tried to remove some test classes to get a smaller set, but at some
point the failure would not reoccur, even when restoring all test
classes and running a clean build.

That points to something like a race condition, or GC-related, or some
other Voodoo (like

I could reproduce going back to
9148f794c168b531d0 2015-03-15 09:25:12 Merge branch 'GROOVY_2_4_X'
(by backporting a jdk9 fix from 83d680877c440)

So this is not related to any recent commit. Also this means I have
checked many gradle versions, and it's not related to any recent
change of gradle versions.

So I believe this looks like either a bug in java9 or an
incompatibility with Java9 of groovy or any library used during

I think it would be worth reporting this at

On Sun, Sep 6, 2015 at 10:14 AM, Thibault Kruse
<> wrote:
> It fails for both a console and a groovysh test. There is some output
> for these tests earlier in the report saying:
> [:groovy-groovysh:test] *** Error in
> `/opt/jdk9-build/j2sdk-image/bin/java': double free or corruption
> (fasttop): 0x00007fe038b0d300 ***
> It might be good to bisect this to the change causing this if possible.
> On Sun, Sep 6, 2015 at 9:16 AM, Pascal Schumacher
> <> wrote:
>> GroovyShell Test all work now :), but now gradle exits with an non-zero exit
>> code when running groovy-console tests with indy:
>> Anybody has an idea why?
>> -Pascal
>> Am 01.09.2015 um 19:19 schrieb Pascal Schumacher:
>>> Merged. Thanks a lot. :)
>>> - Pascal
>>> Am 01.09.2015 um 12:36 schrieb Thibault Kruse:
>>>> See for a possible
>>>> fix
>>>> On Tue, Sep 1, 2015 at 11:13 AM, Thibault Kruse
>>>> <> wrote:
>>>>> The tests makes sure that completing java.util. includes 'Set', as in
>>>>> java.util.Set. I'll assume java9 does not move the Set class. I guess
>>>>> there is a change affecting method
>>>>> PackageHelperImpl.getClassnames(), which was originally copied from
>>>>> jline1.
>>>>> I see it has adaptations for jigsaw made by Cedric:
>>>>> (not pointing fingers, just analyzing the code)
>>>>> And the breaking test follows that new codepath.
>>>>> Debugging a bit, I notice that the files contained in 'jrt:/' does not
>>>>> contains only "/modules/java.base/java/util/Set.class". At a glance,
>>>>> it seems the assumptions in
>>>>> PackageHelperImpl.getPackagesAndClassesFromJigsaw() do not hold with
>>>>> the current Java9 implementation, since it produces a Class
>>>>>, but not java.util.Set.
>>>>> A quick fix is to change:
>>>>> -if (elems) {
>>>>> -   elems = elems[3..<elems.length]
>>>>> +if (elems && elems.length > 2) {
>>>>> +    elems = elems[3..<elems.length]
>>>>> in *two* places in that method.
>>>>> I have no idea whether there is a standard for the folder layout
>>>>> FileSystems.newFileSystem(URI.create("jrt:/")) should return, or
>>>>> whether and why this has changed since Cedric made his additions.
>>>>> However this might be related:

View raw message