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 Mon, 14 Sep 2015 12:00:53 GMT
Actually I was just confused, I did not run against Java9 b80. So I
can still reproduce, and I created a bug report at oracle:


"We are evaluating this report and have assigned it a Review ID:
JI-9024430. In the event this report is determined to be a defect or
enhancement request, it will be referenced with a new Bug ID and will
be listed on Bugs.java.com. For other related issues, please visit our
Bug Database at http://bugs.java.com."


On Wed, Sep 9, 2015 at 8:59 PM, C├ędric Champeau
<cedric.champeau@gmail.com> wrote:
> The build server uses a version of Java compiled from sources for our JDK 9
> build. This custom JVM is built weekly [1], so looking at the history of the
> failing Groovy build, you should be able to find a revision range in the JDK
> that caused the problem. That's what I usually do. We cannot print more
> information than that in the build, because no such information, for custom
> builds, is available. Using this pre-built version already allowed us to
> find JVM bugs before they hit production.
>
> [1]
> http://ci.groovy-lang.org/viewType.html?buildTypeId=OpenJDK_OpenJDK9WeeklyBuild&guest=1
>
>
> 2015-09-09 20:23 GMT+02:00 Thibault Kruse <tibokruse@googlemail.com>:
>>
>> 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