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 Wed, 09 Sep 2015 16:54:06 GMT
Yes, you are right.

I will not raise the bug, but would be happy if you or anybody else does 
it. :)

Cheers,
Pascal

Am 08.09.2015 um 21:25 schrieb Thibault Kruse:
> 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