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.champ...@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 <tibokr...@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 >> <pascalschumac...@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 >> >> <pascalschumac...@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 >> >>>> <tibokr...@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 >> >>>>> <pascalschumac...@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 >> >>>>>>>> <tibokr...@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 >> >>>>>>> >> >>>>>>> >> > > >
