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 <[email protected]>: > 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 > <[email protected]> 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 > >> <[email protected]> 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 > >>>> <[email protected]> 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 > >>>>> <[email protected]> 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 > >>>>>>>> <[email protected]> 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 > >>>>>>> > >>>>>>> > > >
