SpoonLabs / astor

Automatic program repair for Java with generate-and-validate techniques :v::v:: jGenProg (2014) - jMutRepair (2016) - jKali (2016) - DeepRepair (2017) - Cardumen (2018) - 3sfix (2018)
https://hal.archives-ouvertes.fr/hal-01321615/document
GNU General Public License v2.0
205 stars 107 forks source link

CI on Spoon SOS #338

Closed monperrus closed 2 years ago

monperrus commented 2 years ago

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

monperrus commented 2 years ago

first problem was java.lang.RuntimeException: Class java/util/UUID could not be instrumented

reference: https://github.com/SpoonLabs/flacoco/issues/106

monperrus commented 2 years ago

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?

martinezmatias commented 2 years ago

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.

https://github.com/SpoonLabs/astor/blob/dd8e597f117a8f5d1df96ab5682e7cfc638b198f/src/main/java/fr/inria/main/AbstractMain.java#L343

I will fix it

monperrus commented 2 years ago

I will fix it

Great, thanks

monperrus commented 2 years ago

The binary path problem is fixed, see https://ci.inria.fr/sos/job/astor/1077/console

Thanks Matias

monperrus commented 2 years ago

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?

martinezmatias commented 2 years ago

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.

monperrus commented 2 years ago

I already modified the SOS job, it uses Java 11, see https://ci.inria.fr/sos/job/astor/configure

martinezmatias commented 2 years ago

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).

martinezmatias commented 2 years ago

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))

monperrus commented 2 years ago

OK, so we have to switch test in Jenkins. Which one do you recommend?

martinezmatias commented 2 years ago

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)

monperrus commented 2 years ago

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.

martinezmatias commented 2 years ago

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

martinezmatias commented 2 years ago

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

monperrus commented 2 years ago

Thanks a lot Matias, Jenkins is green again: https://ci.inria.fr/sos/job/astor/1079/