Open ssk1216 opened 5 years ago
Is the redundancy policy of finding the code from the same project an obstacle when jgenprog is used to fix student programs????
It depends on the scope of the redundancy. If it's only the current small program, it's a problem, because the pool of ingredients is small. If the scope is larger (like all correct programs of all students, it's less an issue.
In this example, what is the example patch? Does the patch meets the redundancy requirement?
In this example, what is the example patch? Does the patch meets the redundancy requirement?
No patch is generated.
[INFO ] fr.inria.astor.core.faultlocalization.gzoltar.GZoltarFaultLocalization.calculateSuspicious(GZoltarFaultLocalization.java:74) - -Executing Gzoltar classpath: /home/smitha/phD/AstorGUI/./output_astor/AstorMain-testGCD//bin//default from 1 classes with test cases [INFO ] fr.inria.astor.core.faultlocalization.gzoltar.GZoltarFaultLocalization.searchSuspicious(GZoltarFaultLocalization.java:154) - Gzoltar fault localization: min susp value parameter: 0.1 [INFO ] fr.inria.astor.core.faultlocalization.gzoltar.GZoltarFaultLocalization.searchSuspicious(GZoltarFaultLocalization.java:174) - -gz-Adding classpath: [/home/smitha/phD/AstorGUI/./output_astor/AstorMain-testGCD//bin//default] [INFO ] fr.inria.astor.core.faultlocalization.gzoltar.GZoltarFaultLocalization.searchSuspicious(GZoltarFaultLocalization.java:214) - Test failt: testGCD.GCDTest#testinvalidgcd [INFO ] fr.inria.astor.core.faultlocalization.gzoltar.GZoltarFaultLocalization.searchSuspicious(GZoltarFaultLocalization.java:226) - Gzoltar Test Result Total:2, fails: 1, GZoltar suspicious 7, with positive susp 5 [INFO ] fr.inria.astor.core.faultlocalization.gzoltar.GZoltarFaultLocalization.searchSuspicious(GZoltarFaultLocalization.java:234) - nr test results 2 [INFO ] fr.inria.astor.core.faultlocalization.gzoltar.GZoltarFaultLocalization.searchSuspicious(GZoltarFaultLocalization.java:289) - Gzoltar found: 5 with susp > 0.1, we consider: 5 [INFO ] fr.inria.astor.core.solutionsearch.AstorCoreEngine.initPopulation(AstorCoreEngine.java:702) - ---- Creating spoon model [INFO ] fr.inria.astor.core.solutionsearch.AstorCoreEngine.initModel(AstorCoreEngine.java:801) - Creating model, Code location from working folder: /home/smitha/astor/examples/testGCD/src/main/java [INFO ] fr.inria.astor.core.manipulation.MutationSupporter.buildModel(MutationSupporter.java:66) - building model: /home/smitha/astor/examples/testGCD/src/main/java, compliance level: 8 [INFO ] fr.inria.astor.core.manipulation.MutationSupporter.buildModel(MutationSupporter.java:79) - Classpath (Dependencies) for building SpoonModel: null [ERROR] fr.inria.astor.core.solutionsearch.AstorCoreEngine.initModel(AstorCoreEngine.java:808) - Problem compiling the model with compliance level 8 [ERROR] fr.inria.astor.core.solutionsearch.AstorCoreEngine.initModel(AstorCoreEngine.java:810) - The type GCD is already defined [ERROR] fr.inria.astor.core.solutionsearch.AstorCoreEngine.initModel(AstorCoreEngine.java:812) - Astor does not continue when model build fails
It identifies the test which fails but what was a bit confusing is [ERROR] fr.inria.astor.core.solutionsearch.AstorCoreEngine.initModel(AstorCoreEngine.java:810) - The type GCD is already defined**** [ERROR] fr.inria.astor.core.solutionsearch.AstorCoreEngine.initModel(AstorCoreEngine.java:812) - Astor does not continue when model build fails
w.r.t. redundancy policy, Are u trying to say that if testGCD project in src/main/java includes correct versions of GCD code it would be able to look up in the correct program and find a fix ??
Hi @ddkssk909 Could you do a pull request including as failing test case that exposes this problem? Thanks Matias
The type GCD is already defined**** Do you put twice the same class (same fully qualified name) in the source path or the classpath?
Hi @ddkssk909 Could you do a pull request including as failing test case that exposes this problem? Thanks Matias
I did the pull request
The type GCD is already defined**** Do you put twice the same class (same fully qualified name) in the source path or the classpath?
I fixed that. But the current issue I have is ---Starting Solution Search [INFO ] fr.inria.astor.core.validation.processbased.LaucherJUnitProcess.killProcess(LaucherJUnitProcess.java:185) - The Process that runs JUnit test cases did not terminate within waitTime of 10 seconds [INFO ] fr.inria.astor.core.validation.processbased.LaucherJUnitProcess.killProcess(LaucherJUnitProcess.java:187) - Killed the Process that runs JUnit test cases 10483 [INFO ] fr.inria.astor.core.validation.processbased.LaucherJUnitProcess.killProcess(LaucherJUnitProcess.java:185) - The Process that runs JUnit test cases did not terminate within waitTime of 10 seconds [INFO ] fr.inria.astor.core.validation.processbased.LaucherJUnitProcess.killProcess(LaucherJUnitProcess.java:187) - Killed the Process that runs JUnit test cases 10502
My assumption , is the infinite loop in the GCD code is the problem. The expectation was it will find a fix. but now the test is sort of infinite and the o/p is not OK.
Hi @ddkssk909 Could you do a pull request including as failing test case that exposes this problem? Thanks Matias
I had initiated a new pull request on this again.
The below code for GCD has a bug as return b is commented. For a.gcd(0, 5) this will run infinite loop
ASTOR on jgenprog cannot fix it . The code and the Test is below,
--------------------------------- Test cases------------------------------------------ @Test public void testvalidgcd() { assertEquals(2,a.gcd(4, 2) ); } @Test(timeout=5000) public void testinvalidgcd() { assertEquals(5,a.gcd(0, 5) ); }