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
