groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pascal Schumacher <pascalschumac...@gmx.net>
Subject Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Date Tue, 08 Sep 2015 18:44:58 GMT
Hi Thibault,

thanks the detailed analysis. :)

I do not know if it's worth to create a jdk bug, if we can not reproduce 
the bug reliably and can not reduce the set.

-Pascal

Am 06.09.2015 um 16:29 schrieb Thibault Kruse:
> 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 https://en.wikipedia.org/wiki/Heisenbug).
>
> 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 http://openjdk.java.net/jeps/197).
>
> 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
> testing.
>
> I think it would be worth reporting this at http://bugreport.java.com/.
>
>
> On Sun, Sep 6, 2015 at 10:14 AM, Thibault Kruse
> <tibokruse@googlemail.com> 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
>> <pascalschumacher@gmx.net> wrote:
>>> GroovyShell Test all work now :), but now gradle exits with an non-zero exit
>>> code when running groovy-console tests with indy:
>>> http://ci.groovy-lang.org/viewLog.html?buildId=26577&buildTypeId=Groovy_Jdk9Build&tab=buildLog#_focus=85490&state=85490
>>>
>>> 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 https://github.com/apache/incubator-groovy/pull/107 for a possible
>>>>> fix
>>>>>
>>>>> On Tue, Sep 1, 2015 at 11:13 AM, Thibault Kruse
>>>>> <tibokruse@googlemail.com> 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:
>>>>>> https://github.com/apache/incubator-groovy/commit/0e384ec3
>>>>>> (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
>>>>>> java.base.java.util.Set, 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:
>>>>>>
>>>>>> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2014-November/004044.html
>>>>


Mime
View raw message