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 Wed, 09 Sep 2015 18:23:16 GMT
Well, I just tried reproducing multiple times again, now with
java-9-oracle 9.0-b80, and the tests run fine.
So maybe it's already fixed. It could be nice if the buildserver
printed more information, such as the java version used.

On Wed, Sep 9, 2015 at 6:54 PM, Pascal Schumacher
<pascalschumacher@gmx.net> wrote:
> 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