groovy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thibault Kruse <tibokr...@googlemail.com>
Subject Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Date Tue, 08 Sep 2015 19:25:09 GMT
I believe it is the choice of the Java9 team to decide whether to
pursue a flimsy bug report or not. Having this kind of bug in Java9
would be very unpleasant for all Java users, so they should be
greatful if the mere potential for such a bug is mentioned early on. I
don't think this should be a demand for a fix or pushing the
responsibility for finding and fixing the issue to someone else. I
mean just a heads up and asking for ideas on what could go on, or what
information we should provide.

So far I could reliably cause the bug to happen with Gradle, someone
with a working IDE setup could on the Groovy side try to reproduce in
IntelliJ and work with breakpoints to find out more.

Another possibility would be to bisect in the Java9 history to find
the commit where this occurs first (if any).



On Tue, Sep 8, 2015 at 8:44 PM, Pascal Schumacher
<pascalschumacher@gmx.net> wrote:
> 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