Closed monperrus closed 2 years ago
first problem was java.lang.RuntimeException: Class java/util/UUID could not be instrumented
now the problem is that Astor tries to pick /usr/lib/jvm/jdk-11.0.2/java
instead of /usr/lib/jvm/jdk-11.0.2/java
(missing bin
).
[63489] ERROR ProjectConfiguration - The property jvmversion is null or empty
[63496] ERROR main - Error reading the validation process
output:
America/Los_Angeles
/bin/bash: line 4: /usr/lib/jvm/jdk-11.0.2/java: No such file or directory
reference: https://ci.inria.fr/sos/job/astor/1075/console
@martinezmatias how is the Java binary path computed?
The path is computed here: https://github.com/SpoonLabs/astor/blob/dd8e597f117a8f5d1df96ab5682e7cfc638b198f/src/main/java/fr/inria/main/AbstractMain.java#L344
I suspect the bug is present for JDK > 8. At least in Mac (and it seems that also in Linux from the GH CI), the jDK <=8 contains the jre inside, and Astor uses it to run.
I will fix it
I will fix it
Great, thanks
The binary path problem is fixed, see https://ci.inria.fr/sos/job/astor/1077/console
Thanks Matias
However, the test fails:
testMath70PackageSolutionsEvolving(fr.inria.astor.test.repair.approaches.JGenProgEvolutionaryTest) Time elapsed: 0.366 sec <<< ERROR!
java.lang.NullPointerException: null
at fr.inria.astor.test.repair.approaches.JGenProgEvolutionaryTest.testMath70PackageSolutionsEvolving(JGenProgEvolutionaryTest.java:53)
See https://ci.inria.fr/sos/job/astor/1077/console
Not much debug info.
@martinezmatias WDYT?
The bug is still there when we use JDK 11. The Github CI does not detect it because we use Java 8. We should create a new Job that uses Java 11.
I already modified the SOS job, it uses Java 11, see https://ci.inria.fr/sos/job/astor/configure
Yes, I mean the Github Actions CI, which now run on Java 8. That's why the Inria CI fails (Java 11) and the Github Actions CI passes (Java 8).
Well, beyond the bugs we had with the path of the JVM, it seems that there are some tests from Math project that fail on Java 11. Consequently, our plausible patches do not pass the regression (e.g., testMinpackMeyer(org.apache.commons.math.estimation.MinpackTest)
)
OK, so we have to switch test in Jenkins. Which one do you recommend?
let's continue with Java 8 in Jenkins, and to create a new Job in Github CI that test Java 11 (In addition to the existing jobs that test D4J on Java 8)
let's continue with Java 8 in Jenkins,
impossible, because we take the latest Spoon snapshot, which is now 11+, see https://github.com/INRIA/spoon/issues/4179
we just have to identify one test project and the corresponding test which is Java 11 compatible.
impossible, because we take the latest Spoon snapshot, which is now 11+, see INRIA/spoon#4179
Right
we just have to identify one test project and the corresponding test which is Java 11 compatible.
Perfect. I will do it. One option is to simply ignore the test case that fails in Java 11. We can easily do that in Astor
In the Github CI we have now a job that runs a test case with Java 11 (the test is that one executed on the Inria CI). https://github.com/SpoonLabs/astor/runs/3807449259?check_suite_focus=true#step:4:18 The rest of the test are executed in jobs with Java 8
Thanks a lot Matias, Jenkins is green again: https://ci.inria.fr/sos/job/astor/1079/
The Astor job is failing on Spoon SOS https://ci.inria.fr/sos/job/astor/
hard problem with a conjunction of Spoon's move to Java 11 and Flacoco