You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@groovy.apache.org by Pascal Schumacher <pa...@gmx.net> on 2015/08/31 07:38:04 UTC
Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Hello everybody,
I guess PackageHelperImplTest.testLoadAndGetPackagesJavaUtil fails
because of the changes to the jdk packaging:
http://ci.groovy-lang.org/viewLog.html?buildId=26293&tab=buildResultsDiv&buildTypeId=Groovy_Jdk9Build
@Thibault Kruse: Maybe you have an idea how to fix this (as you
implemented the feature :))
-Pascal
Re: Groovy and JDK9 [was Re: Failing Groovysh Test with JDK 9
SNAPSHOT on Buildserver]
Posted by Cédric Champeau <ce...@gmail.com>.
Not without skipping some tests. And JDK9 Jigsaw just introduced some bugs
which make it impossible to build or execute on JDK 9 Jigsaw. We have
submitted a bug report and there's a discussion on the jigsaw list about it.
2015-09-12 11:07 GMT+02:00 Russel Winder <ru...@winder.org.uk>:
> Cédric,
>
> Does Groovy build with Gradle on the JDK9 snapshots?
>
> --
> Russel.
>
> =============================================================================
> Dr Russel Winder t: +44 20 7585 2200 voip:
> sip:russel.winder@ekiga.net
> 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
> London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
>
>
Re: Groovy and JDK9 [was Re: Failing Groovysh Test with JDK 9
SNAPSHOT on Buildserver]
Posted by Russel Winder <ru...@winder.org.uk>.
Cédric,
Does Groovy build with Gradle on the JDK9 snapshots?
--
Russel.
=============================================================================
Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder@ekiga.net
41 Buckmaster Road m: +44 7770 465 077 xmpp: russel@winder.org.uk
London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Posted by Pascal Schumacher <pa...@gmx.net>.
Thibault kindly forwarded me the feedback on the java issue he created
Anybody has an idea how to fix the problem Pallavi is reporting with
building groovy?
-------- Weitergeleitete Nachricht --------
Betreff: Fwd: JI-9024430 : double free or corruption (fasttop)
Datum: Tue, 3 Nov 2015 12:19:55 +0100
I have a response, but now I have less time to deal with this....
---------- Forwarded message ----------
From: Pallavi Sonal <pa...@oracle.com>
Date: Tue, Nov 3, 2015 at 10:01 AM
Subject: JI-9024430 : double free or corruption (fasttop)
Hi Thibault,
Thanks for reporting the incident to Oracle.
I tried building the incubator-groovy project from the Github apache
repository and attached is the output of the build. I didn’t get the
error as reported by you, though build failed with a different error
for me. I had tried the build on Windows 7 OS.
Please let me know if there is a certain configuration/setting that I
may be missing and that may help reproducing the output.
Have you tried building with the latest JDK 9ea B85? Are you still
getting the same error?
Thanks,
Pallavi
To honour the JVM settings for this build a new JVM will be forked. Please consider using the daemon: https://docs.gradle.org/2.8/userguide/gradle_daemon.html.
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy UP-TO-DATE
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes UP-TO-DATE
:buildSrc:jar UP-TO-DATE
:buildSrc:assemble UP-TO-DATE
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build UP-TO-DATE
Bintray user: null
Using Java from D:\JDK9b85 (version 1.9.0-ea)
DM .N$?
$I?7OM.
.7+?II77MZ ,:~~
+I$7O$8? .M..DMMNNMMNZ.
ONDOMI. 7MMMMMMOO$I.
DOM87= ZMNM8NMI77$.
.MNDO?$8$? 8MMNMMMN7II.
MMMO. O$7Z. OI8?MDNNM$$$$7OM
M8 ZZ7$. MMMMMDD7I77I777MMMM.
ZZ$7$ DMM$N$ZNMZDMODNDM. DD
.Z$$I$$ .ZI777777II778 ?D.
8$$7I$I+ .$I7?I7II7D. ?Z
.O$$7I$78 N77O+??I?$. Z
=7$7777$7 . .=7NZ?I$7I+$. O
~:7$$7$7D+$~:=Z:=~++77Z$?IIZ~. N
$Z$7O8D8=Z8I7==I~I:+~OZ887$MOI$O .7
:O$I+~=?:O8?I$=++=:===Z$77ZN++$+~. Z.
:7$78ZZZZZ=ZZ$~?==~+DD$8O$OO$7+?:. $
.=~=+Z7I7?7I$+~=:~+~O~???77?~+??~ O
+=IZ7$7OI$=Z:~:~=8I?I?+$Z8++: N.
=$+8ZO$$==+=~=?=8$IIIIID$ZZ. Z
INDY ENABLED !
Detected development environment
[buildinfo] Properties file path was not found! (Relevant only for builds running on a CI Server)
:copyResources UP-TO-DATE
:ensureGrammars UP-TO-DATE
:exceptionUtils UP-TO-DATE
:compileJava UP-TO-DATE
:dgmConverter UP-TO-DATE
:bootstrapJar UP-TO-DATE
:compileGroovy UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:jar UP-TO-DATE
:groovy-swing:moduleDescriptor UP-TO-DATE
:groovy-swing:compileJava UP-TO-DATE
:groovy-swing:compileGroovy UP-TO-DATE
:groovy-swing:processResources UP-TO-DATE
:groovy-swing:classes UP-TO-DATE
:groovy-swing:jar UP-TO-DATE
:groovy-xml:moduleDescriptor UP-TO-DATE
:groovy-xml:compileJava UP-TO-DATE
:groovy-xml:compileGroovy UP-TO-DATE
:groovy-xml:processResources UP-TO-DATE
:groovy-xml:classes UP-TO-DATE
:groovy-xml:jar UP-TO-DATE
:groovy-templates:compileJava UP-TO-DATE
:groovy-templates:compileGroovy UP-TO-DATE
:groovy-templates:processResources UP-TO-DATE
:groovy-templates:classes UP-TO-DATE
:groovy-templates:jar UP-TO-DATE
:groovy-console:compileJava UP-TO-DATE
:groovy-console:compileGroovy UP-TO-DATE
:groovy-console:processResources UP-TO-DATE
:groovy-console:classes UP-TO-DATE
:groovy-console:jar UP-TO-DATE
:groovy-groovysh:compileJava UP-TO-DATE
:groovy-groovysh:compileGroovy UP-TO-DATE
:groovy-groovysh:processResources UP-TO-DATE
:groovy-groovysh:classes UP-TO-DATE
:groovy-test:compileJava UP-TO-DATE
:groovy-test:compileGroovy UP-TO-DATE
:groovy-test:processResources UP-TO-DATE
:groovy-test:classes UP-TO-DATE
:groovy-test:jar UP-TO-DATE
:groovy-groovysh:compileTestJava UP-TO-DATE
:groovy-groovysh:compileTestGroovy UP-TO-DATE
:groovy-groovysh:processTestResources UP-TO-DATE
:groovy-groovysh:testClasses UP-TO-DATE
:groovy-groovysh:test FAILED
Unexpected exception thrown.
org.gradle.messaging.remote.internal.MessageIOException: Could not write message
[EndOfStream] to '/127.0.0.1:60344'.
at org.gradle.messaging.remote.internal.inet.SocketConnection.dispatch(S
ocketConnection.java:111)
at org.gradle.messaging.remote.internal.hub.MessageHub$ConnectionDispatc
h.run(MessageHub.java:284)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.
onExecute(ExecutorPolicy.java:54)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableE
xecutorImpl.java:40)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:617)
at java.lang.Thread.run(Thread.java:747)
Caused by: java.io.IOException: An existing connection was forcibly closed by th
e remote host
at sun.nio.ch.SocketDispatcher.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:51)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
at sun.nio.ch.IOUtil.write(IOUtil.java:51)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
at org.gradle.messaging.remote.internal.inet.SocketConnection$SocketOutp
utStream.flush(SocketConnection.java:236)
at org.gradle.messaging.remote.internal.inet.SocketConnection.dispatch(S
ocketConnection.java:109)
... 6 more
Unexpected exception thrown.
org.gradle.messaging.remote.internal.MessageIOException: Could not write message
[EndOfStream] to '/127.0.0.1:60355'.
at org.gradle.messaging.remote.internal.inet.SocketConnection.dispatch(S
ocketConnection.java:111)
at org.gradle.messaging.remote.internal.hub.MessageHub$ConnectionDispatc
h.run(MessageHub.java:284)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.
onExecute(ExecutorPolicy.java:54)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableE
xecutorImpl.java:40)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:617)
at java.lang.Thread.run(Thread.java:747)
Caused by: java.io.IOException: An existing connection was forcibly closed by th
e remote host
at sun.nio.ch.SocketDispatcher.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:51)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
at sun.nio.ch.IOUtil.write(IOUtil.java:51)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
at org.gradle.messaging.remote.internal.inet.SocketConnection$SocketOutp
utStream.flush(SocketConnection.java:236)
at org.gradle.messaging.remote.internal.inet.SocketConnection.dispatch(S
ocketConnection.java:109)
... 6 more
Unexpected exception thrown.
org.gradle.messaging.remote.internal.MessageIOException: Could not write message
[EndOfStream] to '/127.0.0.1:60343'.
at org.gradle.messaging.remote.internal.inet.SocketConnection.dispatch(S
ocketConnection.java:111)
at org.gradle.messaging.remote.internal.hub.MessageHub$ConnectionDispatc
h.run(MessageHub.java:284)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.
onExecute(ExecutorPolicy.java:54)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableE
xecutorImpl.java:40)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:617)
at java.lang.Thread.run(Thread.java:747)
Caused by: java.io.IOException: An existing connection was forcibly closed by th
e remote host
at sun.nio.ch.SocketDispatcher.write0(Native Method)
at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:51)
at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93)
at sun.nio.ch.IOUtil.write(IOUtil.java:51)
at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471)
at org.gradle.messaging.remote.internal.inet.SocketConnection$SocketOutp
utStream.flush(SocketConnection.java:236)
at org.gradle.messaging.remote.internal.inet.SocketConnection.dispatch(S
ocketConnection.java:109)
... 6 more
Could not stop org.gradle.messaging.actor.internal.DefaultActorFactory$NonBlocki
ngActor@79d0aaa5.
org.gradle.messaging.dispatch.DispatchException: Could not dispatch message [Met
hodInvocation method: stop()].
at org.gradle.messaging.dispatch.ExceptionTrackingFailureHandler.dispatc
hFailed(ExceptionTrackingFailureHandler.java:34)
at org.gradle.messaging.dispatch.FailureHandlingDispatch.dispatch(Failur
eHandlingDispatch.java:31)
at org.gradle.messaging.dispatch.AsyncDispatch.dispatchMessages(AsyncDis
patch.java:132)
at org.gradle.messaging.dispatch.AsyncDispatch.access$000(AsyncDispatch.
java:33)
at org.gradle.messaging.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:
72)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.
onExecute(ExecutorPolicy.java:54)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableE
xecutorImpl.java:40)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:617)
at java.lang.Thread.run(Thread.java:747)
Caused by: org.gradle.process.internal.ExecException: Process 'Gradle Test Execu
tor 1' finished with non-zero exit value -1073740940
at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNo
rmalExitValue(DefaultExecHandle.java:367)
at org.gradle.process.internal.DefaultWorkerProcess.waitForStop(DefaultW
orkerProcess.java:161)
at org.gradle.api.internal.tasks.testing.worker.ForkingTestClassProcesso
r.stop(ForkingTestClassProcessor.java:86)
at org.gradle.api.internal.tasks.testing.processors.RestartEveryNTestCla
ssProcessor.endBatch(RestartEveryNTestClassProcessor.java:60)
at org.gradle.api.internal.tasks.testing.processors.RestartEveryNTestCla
ssProcessor.stop(RestartEveryNTestClassProcessor.java:54)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionD
ispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionD
ispatch.java:24)
at org.gradle.messaging.dispatch.FailureHandlingDispatch.dispatch(Failur
eHandlingDispatch.java:29)
... 8 more
Could not stop org.gradle.messaging.actor.internal.DefaultActorFactory$NonBlocki
ngActor@624dca6.
org.gradle.messaging.dispatch.DispatchException: Could not dispatch message [Met
hodInvocation method: stop()].
at org.gradle.messaging.dispatch.ExceptionTrackingFailureHandler.dispatc
hFailed(ExceptionTrackingFailureHandler.java:34)
at org.gradle.messaging.dispatch.FailureHandlingDispatch.dispatch(Failur
eHandlingDispatch.java:31)
at org.gradle.messaging.dispatch.AsyncDispatch.dispatchMessages(AsyncDis
patch.java:132)
at org.gradle.messaging.dispatch.AsyncDispatch.access$000(AsyncDispatch.
java:33)
at org.gradle.messaging.dispatch.AsyncDispatch$1.run(AsyncDispatch.java:
72)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.
onExecute(ExecutorPolicy.java:54)
at org.gradle.internal.concurrent.StoppableExecutorImpl$1.run(StoppableE
xecutorImpl.java:40)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.
java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor
.java:617)
at java.lang.Thread.run(Thread.java:747)
Caused by: org.gradle.process.internal.ExecException: Process 'Gradle Test Execu
tor 4' finished with non-zero exit value -1073740940
at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNo
rmalExitValue(DefaultExecHandle.java:367)
at org.gradle.process.internal.DefaultWorkerProcess.waitForStop(DefaultW
orkerProcess.java:161)
at org.gradle.api.internal.tasks.testing.worker.ForkingTestClassProcesso
r.stop(ForkingTestClassProcessor.java:86)
at org.gradle.api.internal.tasks.testing.processors.RestartEveryNTestCla
ssProcessor.endBatch(RestartEveryNTestClassProcessor.java:60)
at org.gradle.api.internal.tasks.testing.processors.RestartEveryNTestCla
ssProcessor.stop(RestartEveryNTestClassProcessor.java:54)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
sorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:520)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionD
ispatch.java:35)
at org.gradle.messaging.dispatch.ReflectionDispatch.dispatch(ReflectionD
ispatch.java:24)
at org.gradle.messaging.dispatch.FailureHandlingDispatch.dispatch(Failur
eHandlingDispatch.java:29)
... 8 more
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':groovy-groovysh:test'.
> Process 'Gradle Test Executor 2' finished with non-zero exit value -1073740940
* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug
option to get more log output.
BUILD FAILED
Total time: 2 mins 54.093 secs
Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Posted by Thibault Kruse <ti...@googlemail.com>.
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
<ce...@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 <ti...@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
>> <pa...@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
>> >> <pa...@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
>> >>>> <ti...@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
>> >>>>> <pa...@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
>> >>>>>>>> <ti...@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
>> >>>>>>>
>> >>>>>>>
>> >
>
>
Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Posted by Cédric Champeau <ce...@gmail.com>.
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 <ti...@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
> <pa...@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
> >> <pa...@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
> >>>> <ti...@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
> >>>>> <pa...@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
> >>>>>>>> <ti...@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
> >>>>>>>
> >>>>>>>
> >
>
Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Posted by Thibault Kruse <ti...@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
<pa...@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
>> <pa...@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
>>>> <ti...@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
>>>>> <pa...@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
>>>>>>>> <ti...@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
>>>>>>>
>>>>>>>
>
Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Posted by Pascal Schumacher <pa...@gmx.net>.
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
> <pa...@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
>>> <ti...@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
>>>> <pa...@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
>>>>>>> <ti...@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
>>>>>>
Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Posted by Thibault Kruse <ti...@googlemail.com>.
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
<pa...@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
>> <ti...@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
>>> <pa...@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
>>>>>> <ti...@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
>>>>>
>>>>>
>
Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Posted by Pascal Schumacher <pa...@gmx.net>.
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
> <ti...@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
>> <pa...@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
>>>>> <ti...@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
>>>>
Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Posted by Thibault Kruse <ti...@googlemail.com>.
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
<ti...@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
> <pa...@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
>>>> <ti...@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
>>>
>>>
>>
Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Posted by Thibault Kruse <ti...@googlemail.com>.
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
<pa...@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
>>> <ti...@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
>>
>>
>
Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Posted by Pascal Schumacher <pa...@gmx.net>.
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
>> <ti...@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
>>>
>
Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Posted by Pascal Schumacher <pa...@gmx.net>.
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
> <ti...@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
Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Posted by Thibault Kruse <ti...@googlemail.com>.
See https://github.com/apache/incubator-groovy/pull/107 for a possible fix
On Tue, Sep 1, 2015 at 11:13 AM, Thibault Kruse
<ti...@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
Re: Failing Groovysh Test with JDK 9 SNAPSHOT on Buildserver
Posted by Thibault Kruse <ti...@googlemail.com>.
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